【问题标题】：How to define DDD Aggregate root for hierarchical data structure?如何为分层数据结构定义 DDD 聚合根？
【发布时间】：2015-08-12 12:08:32
【问题描述】：

我目前正在尝试使领域驱动设计原则适应我的开发实践。而且我一直坚持如何为按层次结构组织的数据定义聚合根。

我们以文件夹结构为例——每个文件夹可以有 0..N 个子文件夹，子文件夹 0..N 也可以有 0..N 个子文件夹，以此类推。

我在一个文件夹及其所有直接和间接子文件夹上都有不变量 - 删除文件夹应该会导致删除它的所有子文件夹

这是否是 DDD 有效的方法让我们说聚合根“文件夹层次结构”，它包含 1 个“文件夹”实体（这将是该文件夹层次结构的“标题”文件夹）并且每个文件夹实体都有 0..N 文件夹实体（子文件夹）

那会是有效的 DDD 吗？那会有效吗？因为我读过 DDD 提倡使用小型聚合，但是这个“文件夹层次结构”可能是一个巨大的聚合......

Is Aggregate Root with Deep Hierarchy appropriate in DDD?

Effective Aggregate Design by Vaughn Vernon

有什么建议可以让这个 DDD 既有效又有效？

编辑

让我们举一个具有树状结构的对象的不同示例。假设我需要开发一个任务跟踪系统，并且该系统需要任务具有非固定级别的子任务 - 所有任务从功能/行为的角度来看都是相同的 - 每个任务可以有 0..1 个父任务和 0 个。 .N 个子任务。

将 Task 作为聚合根（包含所有子任务层次结构）不会遵循 DDD 建议的小型聚合 - 对吗？

根据 DDD 原则，Task 的良好设计是什么？如果Task（带有它的层次结构）不是一个聚合，如何在Task（带有它的所有子任务层次结构）上实现不变量？

【问题讨论】：

文件夹层次结构并不是真正的聚合，它更像是一个存储库。您可以将每个文件夹视为其他文件夹的分组标准。文件夹概念本身可能只是一个名称和一些 ID。很可能这种层次结构更多的是查询问题，即这里没有太多的 DDD。 my post 可能会帮助您了解正在发生的事情。
@MikeSW 我最近在 Pluralsight 观看了域驱动设计基础课程，他们建议为聚合根创建存储库。文件夹只是一些层次结构的一个例子。但是以 Task 为例 - 每个 Task 可以有多个子任务（子任务是子任务等）。如果系统跟踪花费在任务上的时间 - 那么花费在任务上的时间，意味着时间已经花费在它的所有祖先任务（->父任务->父任务->等）上。所以，我认为这意味着任务层次结构的一些不变量，那么如果层次结构不是聚合根，如何建模呢？
DDD 非常主观，因此在对文件夹结构进行建模时，建模任务的设计方法将不适用。没有“这就是某件事的完成方式”可以广泛应用于所有看起来相似的事情/问题。
@AdrianThompsonPhillips 好的，我正在尝试理解 DDD 原则——在这种情况下，如何在 DDD 中对分层相关的对象进行建模。但我明白，这些规则/原则并不是绝对通用的。我将编辑我的问题，以便更具体的商业案例
不要忘记诸如“删除父级时必须删除子级”之类的规则通常可以最终保持一致。拥有几毫秒的孤立节点应该无关紧要。如果确实如此，请不要忘记，在特殊情况下，您还可以在一个事务中修改多个聚合。但是，如果您必须做很多事情，这可能表明您的 AR 边界是错误的。

标签： c# domain-driven-design aggregateroot

【解决方案1】：

您应该围绕不变量对聚合进行建模。一条经验法则是聚合应该一次性加载到内存中（连同它的所有子对象），而不是延迟加载。

你真的有一个需要加载整个层次结构的不变量吗？是否存在需要遍历层次结构中所有节点的情况？要回答这个问题，您需要考虑聚合的用例。

如果您需要所有数据，那么您的聚合具有适当的大小，它不能再小了。如果您的不变量只需要图形的一小部分，那么您可能缺少一些描述该图形部分的域概念。

如果您只关心更新祖先的时间，那么您的任务可能只包含您不需要子集合的 Parent 属性。然后你可以执行类似的操作

public void RegisterTime(TimeSpan time)
{
    TimeSpent += time;
    // maybe more stuff here
    Parent.RegisterTime(time)
}

然后您的存储库将只获得具有他所有祖先的任务，并且聚合将足够小。

我只是猜测，因为它总是取决于用例。

【讨论】：

在考虑不变量时，似乎只有祖先（没有后代层次结构）就足够了，但在用户界面中我需要显示子任务列表 - 以便有可能快速访问所有子任务。因此，从一个角度来看，将导航属性用于子元素是合乎逻辑的，但这会大大增加聚合的大小......
好的，也许解决方案是有一个小的任务聚合（任务+祖先）+所有任务的字典。那么这个 Aggregate 可以有一个任务键列表来快速从字典中获取关于子任务的数据......也许你有一些更好的想法？
一般来说，合适的 DDD 模型不适合向 UI 查询数据。好主意是使用单独的模型来查询数据（您可以搜索 CQRS 以获取更多详细信息，但您必须知道 CQRS 有多种形式）。我通常为读取目的创建单独的 EF 上下文（db first）。它从 db 刷新，因此不需要太多维护。您还可以创建特定视图，将其映射到单独的实体，用于 UI 目的。
好的，谢谢 - 没有其他候选人可以回答我的问题，您的回答很有帮助 - 所以我接受了。