DDD：多少个聚合应具有一个有界上下文？

Question

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

我问这个问题的原因是，书籍和其他资源中的信息过于广泛/抽象。

我想，这取决于某些领域模型及其结构。一个域模型有多少个有界上下文？每个有界上下文中有多少个实体。我想，所有这些问题都取决于这个事实，即在一个有界上下文中应该有多少个聚合。

此外，如果要回顾SOLID原理和通用思想，使它们具有较小的松散耦合代码段。我想，每个单个有界上下文最多具有3-4个聚合是可以的。如果在单一范围内有更多的聚合，那么软件设计可能存在一些问题。

我现在正在阅读有关DDD的弗农书，但是很难理解如何设计这类东西。

Answer 1

  

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

所有聚合都应具有单个有界上下文。您几乎可以反向进行工作-聚合将存储在单个数据库中，数据库将属于单个（微型）服务，服务将为单个有限上下文服务；因此，随之而来的是聚合将属于一个有界上下文。

事情可能会变得混乱：很容易采用一些广泛的业务概念（例如“订单”），并尝试为订单创建适用于每个有界上下文的单一表示形式。不过，这不是目标-目标是使每个上下文都有在该上下文中起作用的顺序表示。

常见示例：销售，开票，履行可能都在乎“订单”，但是他们需要共享的信息基本上只是订单ID，它充当相关标识符，以便他们可以协调对话。

请参见Mauro Servienti：All of Our Aggregates Are Wrong

Answer 2

过时的回答是“足够，但不要太多”。对于将多少个聚合放到有界上下文中，没有真正的指导。

驱动聚合和实体的是用于描述上下文的泛在语言。每种语言的泛在语言都不同，可以在该语言中使用的名词中找到上下文所需的实体和聚合根。一旦用语言完全描述了域，就可以算出在该语言中具有特殊含义的名词，然后就可以算出必要的实体了。

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