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

假设我们有一个微服务M1，其聚合根名为

Player

，还有一个微服务M2，其聚合根名为

Classification

，现在在M1中，我们需要根据

Classification

中的某些属性执行一些逻辑，现在需要执行以下步骤：

通过异步消息传递将可能的分类列表复制到M1

按照M1中业务部门的要求行事 好的，现在假设我们有一个添加玩家的视图，在该视图中可以从下拉列表中选择新玩家的

分类。现在的问题是：

下拉列表中是否应该填充复制到M1或M2的分类

如您所见，通过使用M1中的数据，我们必须通过API公开M1中的
分类
，因此是问题的标题

编辑

复制是通过使用事件的异步消息传递进行的，因此我不会将整个聚合公开给M1，而只是一些属性，如Id和分类描述。
我相信两者都可以完成，一个并不比另一个好。无论哪种方式，您都在对M2进行API调用，以获取
分类。但这个场景现在告诉您，服务边界可能是错误的——视图上创建新玩家的垂直部分可能应该是单个微服务。当然，您将为对M2的调用添加一些回退机制，以便在M2失败的情况下，M1不会完全失败（在本例中，创建一个新的播放器）。
设计微服务时的主要思想是，一个微服务不应该对任何其他微服务进行任何同步调用。这意味着每个微服务在响应查询或执行命令之前，都应该以异步模式收集任何所需的外部状态。一种方法是（1）订阅事件；另一种方法（2）是定期查询一些公开的读取模型（请参阅），即在
cron
作业中

在任何情况下，您都不应该公开整个聚合，否则可能会因依赖其内部结构而破坏其封装。相反，您应该发布其域事件（1）或创建一个专门设计的规范Readmodel，将最可能的模型呈现给其他微服务；类似于标准的阅读模型；除非域太简单、太粗糙，否则我会避免这种情况。
您应该将每个微服务视为服务边界。表示任何聚合都不会离开有界上下文。这样做的原因是，如果你这样做了，你的领域知识就会泄漏到其他有界的上下文中，并且对它有着很强的依赖性。聚合上的任何更改都将破坏任何依赖的服务

如果需要从其他有界上下文检索数据，则应通过反损坏层进行检索。就可以转换为DTO的微服务而言。这样，当您添加或删除属性时，就不必破坏与外部上下文的契约

从提供的信息很难判断
Player
和
Classification
是否属于同一上下文。基本上，从多个微服务（即，在同一个UI表单上显示订单和送货单，而它们来自不同的边界上下文，即订单和物流）组合UI数据没有什么错

但是，如果您的
Player
model/aggregates直接相互依赖，并且两者都不能独立于另一个单独使用，那么它很可能是同一个有界上下文的一部分
 这些API调用将在哪里进行？我说过复制是通过使用异步消息和事件进行的。没有从一个微服务到另一个微服务的API调用。我不同意一个微服务不允许对任何其他微服务语句进行任何同步调用。这是非常固执己见的，从本质上来说，没有什么能阻止你这么做，也没有那么糟糕。但我们应该避免它，因为它会导致微服务之间的依赖性，并损害系统的可伸缩性，毕竟有些系统只需要外部调用（即IdentityServer4来解析引用托克（尽管在第一次命中后缓存）和撤销）@Tseng我不同意。分布式系统环境下的可伸缩性（也包括微服务）是隐含的，因此给出“如果你想拥有一个可伸缩的系统，那么……”这样的回答是毫无意义的。现实世界中的大多数微服务从未超过它们需要扩展到一个或两个以上实例的程度。微服务更有益的属性是更快的部署周期（当您只修复单个微服务中的错误时，您只需部署整个单一应用程序即可）、解耦、更易于替换/重写单个微服务以及最后但并非最不重要的多语言编程（使用不同的语言和环境来处理微服务。由于上面提到的原因，缩放只是一个方面，甚至不是最重要的一个。”曾恩，“弹性”是什么？你认为弹性是重要的吗？只说不允许是完全错误的，因为它听起来像是一个规则，它不存在。这只是你的观点。关于。不建议或应该避免将是更合适的，一个人只需要知道后果。我同意每个词，但在我的情况下，
分类
取决于另一个有界上下文，因为定义现有分类的人是管理区域和上下文，
玩家
只需选择一个分类从列表中删除。@Tseng反腐败层不是唯一的有界上下文之间的层。公开从另一个BC复制的数据有什么让您如此担心的？在您的情况下，它将是只读的，对吗？是的，它会