我对DDD中的聚合根概念有点困惑。理论告诉它它应该是一个与当前操作相关的聚合根。
例如，我有一个root帐户，代表一家公司。它有地址，属于该帐户的用户，以及其他一些属性。
我有几页;一个是管理一般信息，如姓名，电子邮件，电话...... 另一个是维持地址。 还有一个显示所有用户（并编辑用户信息，也可能在Account对象下）
在第一种情况下，我不在乎地址，在第二种情况下，我并不关心姓名，电子邮件......
我是否需要两个单独的Account对象，或者我只需要一个帐户？ （该模型可能比我描述的更复杂）
因此，例如，我最终可能会遇到类：BasicAccountInformation，AccountAddress，AccountUsers .... 或者只是一个：包含所有数据的帐户？
正确的DDD方法是什么？我认为，在一种情况下，我将得到一个包含许多属性和逻辑的非常复杂的类;或者很多简单的类，每个类有2-10个属性。
答案 0 :(得分：1)
我需要多少聚合根？
至少一个。
聚合用作一致性边界。如果您将整个域建模为单个聚合，并提供一个＆＃34;聚合根＆＃34;确保每次写入都能保持您的业务不变性，您就可以了。
嗯，你慢慢走好。聚合根作为聚合边界中所有状态的一种序列化瓶颈。如果您希望同时更新模型的两个不同部分＆＃34;那么您将需要对业务不变量的责任进行分区。我有两页;一个是管理一般信息，如姓名，电子邮件，电话......另一个是维护地址。
报告很棒。它们会告诉您需要为模型收集哪些数据。
但报告很糟糕，告诉您聚合的位置 - 您的聚合的主要关注点不是读取/呈现/报告您的数据，而是编写数据。
通过在执行写入时查找模型中需要组合在一起的数据，可以找到聚合。您需要哪些数据来强制执行业务不变量？
该启发式算法往往会吸引CRUD域，因为模型的大多数状态都独立于其他域。
你可以看看实体关系;如果两个聚合＆＃34;分享＆＃34;一个实体，那么该实体可能属于第三个聚合。
您可以看到的另一件事是实体生命周期。如果子实体可以比聚合根更长，那么您就知道您已将其建模错误。
根据你描述的内容，这在这里也没有多大帮助;你有效地得到了帐户，还有一堆住在其中的东西。
有时候所有这些都失败了，你最终会使用启发式＆＃34;我只想偶尔加载一次数据＆＃34;，你只需将它加入一个键值存储区然后再回到提供商业价值。