domain-driven-design - 哪些实体应该是聚合根？

Question

如果 Book 聚合 Chapter 又聚合 Page ，那么聚合根应该是什么？一种可能性可能是:

Book是以Chapter为叶的聚合根，Chapter是以Page为叶的聚合。

在这种情况下，Chapter 是一个聚合中的叶子和另一个聚合中的根。这个可以吗？在这种情况下，有两个存储库是否有意义，一个用于 Book，另一个用于 Chapter？如果是这样，那么不能使用 Chapter 存储库来规避只能通过 Book 访问 Chapter 的事实吗？处理这种情况的最佳方法是什么？

Answer 1

在我看来，只有当给定的聚合只有一个根时，聚合根的整个想法才有意义。哪一个 - 这取决于您的要求。让我们检查两种可能性:

Book 是一个根，它包含包含页面的章节。当您的使用场景都包括与书籍交互时，此设计很有用:用户选择书籍并将其操作/命令应用于整本书。请注意，Book 聚合位于域模型的“操作”层——作为一个整体，它代表了日常业务的概念。

章是根。是包含页面。它还引用了Book。当使用场景侧重于与各个章节进行交互时，这种设计很有用。章节聚合现在位于“操作”层。书籍本身形成一个集合，但被放置在操作层下方的“潜力/能力”层中。这意味着书籍是组织的 Assets ，是业务的插入者，但不是日常事件的一部分。此外，书籍对被章节引用一无所知。

总而言之，一切都取决于您的案例的具体情况，您的要求。请注意，域模型中的层主要是一个业务概念，而不是技术概念——它们帮助您很好地建模域。更多信息请阅读 Eric Evans 的领域驱动设计，尤其是“大规模结构”部分。