哪些对象负责维护聚合之间的引用？

Question

假设我有一个聚合Ticket。 Ticket将指定一个Department，一个或多个指定Employee。

1. 在实例化Ticket时，TicketFactory是否应负责确保使用有效/现有Ticket和{{1}创建Department }

2. 同样，在停用Employee或Department时，有什么责任确保将新的Employee或Department分配给Employee为了维持它的不变量？是否可以在负责退役的域中提供服务，或者是否应采用最终一致性或某种形式的事件监听？

Answer 1

1. TicketFactory将声明为了创建Ticket，您需要引用Department和Employee。它不会验证那些实际存在。调用代码负责获取适当的引用。

2. 如果使用最终一致性，Department和Employee的退役将发布指示退役的事件。会有一个与Ticket相关联的处理程序，它会订阅该事件并分配新的部门和员工，或者向任务发送某种警告。

请查看Effective Aggregate Design了解更多信息。

Answer 2

我最近开始探索DDD，所以我遇到了你提到的一些问题。

1. 我认为TicketFactory应始终返回经过验证/正确构建的Ticket实例。如果您的模型很复杂，您可以使用域服务验证给定的Department或Employee是否可以附加到它，然后工厂使用它。否则，你可以把它全部放在工厂里。但是工厂出来的应该是一张合适的票。

2. 我会说，如果是只有Ticket知道其他两个，使用Department和Employee repos的域名服务才能完成工作。如果关系是双向的，那么您可以利用事件来源。此外，如果它确实是应该在您的域模型中捕获的事件，并且除了重新洗牌之外还有其他后果，您可以将其中一个处理程序附加到此事件InvalidTicketHandler。但如果它是一个小规模的东西，保持简单，只需要一个维护不变量的域服务。

旁注：如果Department和/或Employee本身是聚合，那么您可以通过其标识符在Ticket内引用它们（例如，员工的公司ID或部门的ID代码） ）。通过这种方式，您可以更轻松地实现一致性，因为您不会跨越不同聚合之间的一致性边界。

Answer 3

1.   

   FACTORY负责确保对象或其创建的AGGREGATE满足所有不变量;但在删除应用于该对象外部的对象的规则之前，您应该始终三思而后行。 FACTORY可以将不变检查委托给产品，这通常是最好的。 [领域驱动设计：解决软件核心的复杂性]

2. A取决于问题类型，但从它的外观来看，它似乎是应用程序层功能的一个很好的候选者，我不会去寻找事件解决方案，因为我发现它只适用于层和而不是在同一层中的对象之间。