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

如果书聚合了章节，而章节又聚合了页面，那么聚合根应该是什么？一种可能是：

书是以章为叶的聚合根，章是以页为叶的聚合

---

在这个场景中，章节在一个聚合中是一片叶子，在另一个聚合中是一个根。这样行吗？在这个场景中，有两个存储库，一个用于书籍，另一个用于章节，有意义吗？如果是这样的话，那么章节存储库就不能用来规避这样一个事实：只有通过Book才能访问章节？处理这种情况的最好办法是什么

在我看来，只有当给定集合只有一个根时，集合根的整个概念才有意义。哪一个--这取决于您的需求。让我们研究两种可能性：

书是根目录，它包含包含页面的章节。当您的使用场景都包括与书籍交互时，此设计非常有用：用户选择书籍并在整个书籍上应用其操作/命令。请注意，Book aggregate位于域模型的“operations”层——它作为一个整体表示日常业务的一部分

章是根。Is包含多个页面。它还参考了这本书。当使用场景侧重于与各个章节交互时，此设计非常有用。章节聚合现在位于“操作”层。书本身形成一个集合，但被放置在操作层下面的“潜力/能力”层中。这意味着书籍是组织的资产，是业务的推动者，但不是日常活动的一部分。此外，书籍对章节的引用一无所知

---

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

谢谢Szymon。这些都是澄清决策背后原因的好观点。如果可以的话，我想稍微扩展一下情况：假设这本书也包含作者。如果您支持两个用例，一个关注章节（及其页面集合），另一个关注书籍（及其作者集合），那么您现在有理由在一个场景中将章节作为聚合根，在另一个场景中将书籍作为聚合根。但这本书包含章节，所以我们有一个聚合根，它包含另一个聚合根。现在呢？一些DDD专家（如Udi Dahan）承认聚合根不是模型的结构元素，可以根据特定用例进行不同的放置。这可以解决你的问题。在“聚合”一书中，章节和书籍都可以是不同用例中的聚合根。此处描述了此方法：。然而，每个用例的聚合根不是“经典”DDD原则之一，并且是许多讨论的主题。是的。这是有道理的。感谢Udi文章的链接。这很有趣。