如何为分层数据结构定义 DDD 聚合根?

Pro*_*ors 5 c# domain-driven-design aggregateroot

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

让我们以文件夹结构为例 - 每个文件夹可以有 0..N 个子文件夹,子文件夹 0..N 也可以有 0..N 个子文件夹等等。

我在文件夹及其所有直接和间接子文件夹上有不变量 - 删除文件夹应导致删除所有子文件夹

这是否是 DDD 有效方法,让我们说聚合根“文件夹层次结构”,其中包含 1 个“文件夹”实体(即该文件夹层次结构的“标题”文件夹),并且每个文件夹实体具有 0..N 个文件夹实体(子-文件夹)

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

具有深层层次结构的聚合根在 DDD 中是否合适?

Vaughn Vernon 的有效聚合设计

任何建议如何使 DDD 既有效又有效?

编辑

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

拥有Task作为聚合根(所有它的子任务层次结构)不会遵循 DDD 建议的小聚合 - 对吗?

Task根据 DDD 原则,什么是好的设计?Task如果Task(具有层次结构)不是聚合,如何在(具有所有子任务层次结构)上实现不变量?

Mac*_*het 2

您应该围绕不变量对聚合进行建模。一条经验法则是聚合应该一次性加载到内存(及其所有子对象),而不是延迟加载。

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

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

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

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

然后你的存储库将只获得包含其所有祖先的任务,并且聚合将足够小。

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

  • 一般来说,正确的 DDD 模型不适合向 UI 查询数据。好主意是使用单独的模型来查询数据(您可以搜索 CQRS 以获取更多详细信息,但您必须意识到 CQRS 有多种形式)。我通常创建单独的 EF 上下文(首先是数据库)用于读取目的。它是从数据库刷新的,因此不需要太多维护。您还可以创建特定视图,将其映射到将用于 UI 目的的单独实体。 (2认同)