有多少聚合应该具有单个边界上下文？
我问这个问题是因为书籍和其他资源的信息过于广泛/抽象。
我想，这取决于某些领域模型及其结构。有多少个边界上下文具有域模型？每个边界上下文中有多少个实体。我想，所有这些问题都依赖于这个事实，即在单个有界上下文中应该有多少聚合。
另外，如果要回想一下 SOLID 原则和共同的想法，即拥有松散耦合的小代码段。我想，每个边界上下文最多有 3-4 个聚合是可以的。如果单个边界上下文中有更多聚合，则软件设计可能存在一些问题。
我现在正在读弗农关于DDD的书，但很难理解如何设计这些东西。
陈词滥调的答案是"刚刚好，但不要太多"。 对于在有界上下文中放置多少聚合，没有真正的指导。
驱动聚合和实体的东西是用于描述上下文的无处不在的语言。 无处不在的语言对于每个上下文都是不同的，上下文中所需的实体和聚合根可以在语言中使用的名词中找到。 一旦你用语言完全描述了领域，计算在该语言中具有特殊含义的名词，你就有了必要的实体的计数。
但请记住，我很少遇到"完全描述"的有限上下文。 目标"对此版本进行了充分的描述"。 因此，对于任何版本，实体的数量都不会"足够"，您可能会计划添加更多实体。 这些计划是否会上升到优先级队列的顶部是另一个问题。
有多少聚合应该具有单个边界上下文？
所有聚合都应具有单个边界上下文。 你几乎可以反向计算 - 聚合将存储在单个数据库中，数据库将属于单个(微(服务，服务将服务于单个边界上下文;因此，聚合将属于单个有界上下文。
事情可能变得混乱的地方：很容易采用一些广泛的业务概念，如"订单"，并尝试为订单创建一个适用于每个边界上下文的单一表示形式。 不过，这不是目标 - 目标是让每个上下文都有一个在该上下文中工作的顺序表示。
常见示例：销售、计费、履行可能都关心"订单"，但他们需要共享的信息主要只是订单 ID，它充当相关标识符，以便他们可以协调对话。
参见Mauro Servienti：我们所有的聚合都是错误的