如果Book聚合章节反过来汇总了Page，那么聚合根应该是什么？一种可能性可能是：
Book是一个聚合根，其中Chapter作为leaf，而Chapter是一个以Page作为leaf的聚合。
在这种情况下，Chapter是一个聚合中的叶子，另一个是根。这个可以吗？在这种情况下，有两个存储库是有意义的吗，一个用于Book，另一个用于Chapter？如果是这样，那么章节存储库是否可以用来规避只有通过Book才能访问章节的事实？处理这种情况的最佳方法是什么？
答案 0 :(得分：2)
在我看来，只有当给定聚合的单个根时，聚合根的整个概念才有意义。哪一个 - 这取决于您的要求。让我们来看看两种可能性：
Book是一个根，它包含包含Pages的章节。当您的使用场景都包括与书籍交互时，此设计非常有用：用户选择书籍并在整本书籍上应用他们的操作/命令。请注意，Book聚合在您的域模型的“操作”层中 - 它作为一个整体，代表了日常业务的概念。
章节是根。包含页面。它也参考了Book。当使用场景专注于与各个章节交互时，此设计非常有用。章聚合现在位于“操作”层。书本身形成一个聚合体，但是被放置在操作层下面的“潜在/能力”层中。这意味着书籍是组织的资产，是企业的推动者，但不属于日常活动的一部分。此外，书籍对章节的引用一无所知。
总而言之，一切都取决于您的具体情况，您的要求。请注意，域模型中的层主要是业务概念，而不是技术概念 - 它们可以帮助您很好地建模域。欲了解更多信息，请阅读Eric Evans的领域驱动设计，特别是“大规模结构”部分。