时间戳

首页 > 解决方案 > 在微服务中，是否可以接受 API 返回已复制的聚合根？

domain-driven-design - 在微服务中，是否可以接受 API 返回已复制的聚合根？

问题描述

想象一下，我们有一个微服务 M1，其聚合根称为Player，微服务 M2 其聚合根称为ClassificationClassification

  1. 通过异步消息将可能的分类列表复制到 M1；
  2. 做M1中业务要求的事情；

好的，现在假设我们有一个添加 Players 的视图，并且在该视图中可以从下拉列表中选择Classification新的。Player现在的问题：

下拉列表应该填充复制到 M1 还是从 M2 的分类？

如您所见，通过使用来自 M1 的数据，我们必须Classification通过 API 公开来自 M1 的数据，这就是问题的标题。

编辑

复制是通过使用事件的异步消息传递发生的，因此我不会将整个聚合暴露给 M1，而只是将一些属性（如 Id 和分类的描述）暴露给 M1。

标签： domain-driven-designmicroservicesmultiple-databasesaggregateroot

解决方案

设计微服务时的主要​​思想是一个微服务不应该对任何其他微服务进行任何同步调用。这意味着每个微服务都应该在响应查询或执行命令之前以异步模式收集任何所需的外部状态。一种方法是（1）订阅事件；另一种方式（2）是通过定期查询一些公开的读取模型（参见CQRS），即在cron工作中。

在任何情况下，您都不应该暴露整个聚合，否则您可能会因依赖其内部而破坏其封装。相反，您应该发布其领域事件 (1) 或创建一个专门设计的规范 Readmodel，将最可能的模型呈现给其他微服务；类似于规范的读取模型；我会避免这种情况，除非域太简单，太 CRUD。

推荐阅读