希望这个虚构的例子能说明我的问题：
假设您正在编写一个系统来跟踪软件产品的投诉以及有关该产品的许多其他属性。在这种情况下，SoftwareProduct 是我们的聚合根，而 Complaints 是只能作为产品子项存在的实体。换句话说，如果软件产品从系统中删除，那么投诉也应如此。
在系统中，有一个类似网页的仪表板，显示单个软件产品的许多不同方面。仪表板中的一个部分以类似网格的方式显示投诉列表，仅显示每个投诉的一些非常高级的信息。当管理员类型的用户选择其中一个投诉时，他们会被引导到一个编辑屏幕，允许他们编辑单个投诉的详细信息。
问题是：编辑屏幕检索单个投诉的最佳方式是什么，以便可以显示以进行编辑？请记住，我们已经将 SoftwareProduct 建立为聚合根，因此不应允许直接访问投诉。此外，系统正在使用 NHibernate，因此可以选择急切加载，但我的理解是，即使通过 SoftwareProduct 急切加载单个投诉，只要访问投诉集合，就会加载集合的其余部分。那么，如何通过 SoftwareProduct 获得单个投诉，而不会产生加载整个投诉集合的开销？
这有点涉及语义和宗教信仰，但在编辑投诉的上下文中，投诉是根对象。当您编辑投诉时，父对象（软件产品）并不重要。它显然是一个具有唯一身份的实体。因此，您将拥有一个专门用于保存更新的投诉等的服务/存储库。
另外，我觉得你有点太消极了。投诉？“评论”怎么样？还是“建设性批评”？
@乔希，
我不同意你所说的，尽管我注意到有些人以这种方式设计他们的“Web”应用程序只是为了性能，而不是基于域模型本身。
我也不是 DDD 专家，但我相信您已经阅读过传统的 Order 和 OrderItem 示例。所有 DDD 书籍都说 OrderItem 属于 Order 聚合，而 Order 是聚合根。
根据您所说的，OrderItem 不再属于 Order 聚合，因为用户可能希望直接编辑 OrderItem 不重要的 OrderItem（就像编辑 Complaing with its parents Software Product 不重要一样）。而且您知道，如果遵循这种方法，则无法强制执行任何 Order 不变量，这对于电子商务系统而言极为重要。
有人有更好的方法吗？
莫什
要回答您的问题：
聚合用于一致性的目的。例如，如果从父对象（聚合根）添加/修改/删除子对象会导致不变量破坏，那么您需要在那里进行聚合。
但是，在您的问题中，我相信 SoftwareProduct 和 Compliant 属于两个单独的聚合，每个聚合都是它们自己聚合的根。您不需要加载 SoftwareProject 和分配给它的所有 N 个投诉，只需添加一个新的投诉。对我来说，添加新投诉时似乎没有任何需要评估的业务规则。
因此，总而言之，创建 2 个不同的存储库：SoftwareProductRepository 和 ComplaintRepository。
此外，当您删除软件产品时，您可以使用数据库关系来级联删除并删除关联的投诉。出于数据完整性的目的，这应该在您的数据库中完成。您不需要在域模型中控制它，除非您除了删除链接对象之外还有其他不变量。
希望这可以帮助，
莫什
我将 NH 用于另一个业务环境，但与您的实体关系类似。我不明白你为什么说：
请记住，我们已经将 SoftwareProduct 建立为聚合根，因此不应允许直接访问投诉
我有这个，Article实体Publisher，如果Publisher不复存在，所有依赖的Artcle实体也会存在。我允许自己直接访问每个实体的Article集合。Publisher在Article类的 DB/Mapping 中，Publisher是成员之一，不能接受Null.
想详细说明你和我的区别吗？
抱歉，这不是一个直接的答案，但太长了，无法作为评论添加。
我同意莫什的观点。这两个实体中的每一个都有自己的聚合根。让我在现实生活中解释一下。假设一家公司开发了一个软件。这个软件有一些bug，让你很恼火。你要去公司并从这个问题中了解他们。这家公司给你一张表格，由你填写。
此表格有一个字段 - 部分 - 指示软件名称和描述。此外，它还有一些可以投诉的部分。这个表格和软件说明书一样吗？不是，是与软件相关的表格。它不是软件。这个表格有ID吗？是的。它有。也就是说，您可以在第二天致电公司，向接线员询问您的投诉信。很明显，接线员会询问您有关 ID 的信息。
这一证据表明，这种形式有自己的实体，不能与软件本身混淆。两个不同实体之间的任何关系并不意味着它们中的一个属于另一个。