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

Question

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

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

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

此外，如果回忆一下 SOLID 原则和拥有松散耦合的小代码段的共同想法。我想，每个有界上下文最多可以有 3-4 个聚合。如果单个有界上下文中有更多聚合，则软件设计可能存在一些问题。

我现在正在阅读 Vernon 的关于 DDD 的书，但是很难理解如何设计这些东西。

Answer 1

老生常谈的答案是“刚好够用，但不要太多”。关于在有界上下文中放置多少聚合没有真正的指导。

驱动聚合和实体的是用于描述上下文的通用语言。无处不在的语言对于每个语境都是不同的，语境中需要的实体和聚合词根可以在语言中使用的名词中找到。一旦你有了语言完全描述的领域，计算在该语言中具有特殊含义的名词，你就有了必要实体的数量。

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

Answer 2

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

所有聚合都应该有一个单一的有界上下文。您几乎可以向后计算 - 聚合将存储在单个数据库中，数据库将属于单个（微）服务，服务将服务于单个有界上下文；因此，聚合将属于单个有界上下文。

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

常见的例子：销售、计费、履行可能都关心“订单”，但他们需要共享的信息很大程度上只是订单 ID，它充当关联标识符，以便他们可以协调对话。