DDD：我需要多少聚合根？

Question

我有点困惑于DDD中的聚合根概念。该理论告诉它，它应该是一个与当前操作相关的聚合根。

例如，我有一个根帐户，它代表一个公司。它具有地址，属于该帐户的用户以及其他一些属性。

而且我有几页;一个是管理一般信息，如姓名，电子邮件，电话... 另一个是维护地址。 再一次显示所有用户（并编辑用户信息，这可能也在帐户对象下）

在第一种情况下，我不在乎地址，在第二个我不关心名称，电子邮件.. ..

我需要两个单独的Account对象吗？或者我只需要一个Account？ （该模型可能比我描述的更复杂）

因此，举例来说，我可能最终与类：BasicAccountInformation，AccountAddress，AccountUsers .... 或者只是一个单一的：帐户其中包含的所有数据？

什么是正确的DDD方法？我认为，在某种情况下，我会得到一个非常复杂的类，其中包含很多属性和逻辑;或者每班有2-10个属性的很多简单类。

Answer 1

我需要多少个聚合根？

至少有一个。

集合充当一致性边界。如果您将整个域作为单个聚合进行建模，并提供一个“聚合根”来确保您的业务不变量由每次写入保持不变，那么您就很好。

那么，你很好走，慢慢来。聚合根是整个边界中所有状态的一种序列化瓶颈。如果您希望“同时”更新模型的两个不同部分，那么您将需要划分业务不变的责任。

而且我必须页;一个是管理一般信息，如姓名，电子邮件，电话......另一个是维护地址。

报告很棒。他们会告诉您需要为您的模型收集哪些数据。

但是报告很不情愿，告诉你你的聚合的位置 - 聚合的主要关注点不是读取/显示/报告你的数据，而是写它。

您可以通过在执行编写时查找需要分组在一起的模型上的数据来查找聚合。您需要哪些数据来执行业务不变量？

启发式倾向于吸引CRUD域，因为大多数模型的状态与其他模式无关。

您可以查看实体关系;如果两个集合“共享”一个实体，那么该实体可能属于第三个集合。

你可以看到的另一件事是实体生命周期。如果一个子实体能够超过聚合根，那么你知道你已经将它建模为错误的。

根据你所描述的，这在这里也没什么帮助;你已经有效地获得了账户，以及其中的一些东西。

有时候所有这些都会失败，并且最终会使用启发式的“哪些数据我只想暂时加载一次”，并且您只需将它压缩到关键值存储区并返回到交付业务价值。