问DDD:有多少个聚合应该有一个有界的上下文？

EN

陈词滥调的回答是“只够了，但不多”。对于在一个有限制的上下文中放置多少个聚合没有真正的指导。

驱动聚合和实体的东西是用来描述上下文的无处不在的语言。普遍存在的语言对于每个语境是不同的，在上下文中所需的实体和聚合根可以在语言中使用的名词中找到。一旦你有了语言完全描述的领域，就数出在该语言中有特殊意义的名词，你就有了必要的实体计数。

不过，请记住，我很少遇到“完全描述”的有限上下文。目标是“对此发布的描述足够充分”。因此，对于任何版本，实体的数量都是“不够”的，您可能会计划添加更多的实体。这些计划是否会上升到优先级队列的顶端是另一个问题。

有多少个聚合应该有一个有界上下文？

所有聚合应该有一个有界的上下文。您几乎可以反向处理--聚合将存储在单个数据库中，数据库将属于单个(微)服务，服务将服务于单个有界上下文；因此，聚合将属于单个有界上下文。

在事情可能变得混乱的地方:很容易采取一些宽泛的业务概念，比如" order "，并尝试为order创建一个适用于每个有限上下文的单一表示。但这并不是目标--目标是让每个上下文都有一个在这个上下文中工作的顺序表示。

常见的例子:销售、计费、履行都可能关心“订单”，但他们需要共享的信息主要是订单id，它充当了一个相关标识符，以便他们能够协调对话。

见Mauro Servienti：我们所有的人都错了