如何在域驱动器设计中设计自引用聚合

Question

我在一个任务系统上工作,其中一个任务可以有集合子任务,子任务可以有子任务的集合等等(递归).

DOMAIN

task给出的是基于Organizational Chart

示例组织结构图:

Mahdi
---Saeed
------Jaime
------Ahmed
---Tarawneh
------Mae
---Rasheed

组织结构图上的上层人员将任务分配给他下面的人.

让我们说马赫迪将把任务分配给赛义德命名prepare course materials for IELTS.

然后,赛义德可能会将任务划分为子任务.

prepare course materials for IELTS
---issue laptop and equipment (assigned to Jaime)
---prepare the checklist form(assigned to Ahmed)

然后,如果它真的是一项重大任务,Jaime可能会将其进一步划分为子任务.

根据领域专家的说法,它通常低于3级

不变量:

编辑

我是否必须坚持这个Task概念,或者仍然存在像MainTask和SubTask这样的概念(只是一个例子)？

如果我坚持这个Task概念,我应该加载整个图表还是只加载直接的父母和孩子？

或者我应该将所有工作委托给域名服务吗？这可能会把任务变成贫血模型？

Answer 1

您应该阅读Vaughn Vernon关于有效聚合设计的系列文章; 他探索的问题域与你描述的相似.

在移动任务的截止日期时,应该检查它是否应该超过其父任务的截止日期

如果此不变量失败,业务成本是多少？

如果错误的最后期限是一个必须要防止的昂贵问题,那么你将被迫进入一个设计,任务图的所有截止日期都需要包含在一个聚合边界内(因为最终,所有的写入任务截止日期需要立即与根任务的截止日期一致).

但是,在写入发生后检测并不是特别困难的条件.如果你可以放宽限制 - 允许"无效"的最后期限,但实现检测它们并修复它们的能力 - 那么你就可以更灵活地放置边界.

您的状态要求中的问题是类似的:如果您需要立即更新状态更新,如果您需要在单个事务中将状态更改的写入级联到任务图,那么所有任务状态都需要处于相同的聚合边界.

如果不是这样的话; 如果足以看到子任务已完成,并在单独的事务中更新父任务状态,那么您可以更灵活地绘制聚合边界.

我的猜测是你要避免为每次写入加载整个任务图.如果所有任务都是同一聚合的一部分,那么您一次只能更新一个任务.立即一致性意味着更多的写入争用; 您需要与域专家坐下来,确保每个人都了解哪些对业务更重要.

我只能更新分配给我或我分配给的任务状态.

我只能向直接在我这里的员工提供任务

同样,这对企业真的有价值吗？这真的是您的任务分配环境的一部分,还是责任属于授权？

您还需要考虑记录簿的内容.如果您的模型是谁向谁报告的权限,那么尝试强制执行报告链的连接任务分配的不变量可能是有意义的.但是,如果像大多数组织一样,报告链是在现实世界中决定的,那么模型实施严格约束并不真正有意义,因为它的数据副本是陈旧的.

任务分配可能类似 - 一些经理正在决定委派一些工作,而只是通知系统就是这种情况.

在这些情况下,当现实世界违反业务规则时,系统应该跟踪它,而不是试图假装它不会发生.