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

Question

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

1. 在实例化TicketFactory Ticket ， TicketFactory应该负责确保使用有效/存在的Department和Employee创建TicketFactory Ticket ？

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

Answer 1

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

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

有关详细信息，请参阅有效聚合设计 。

Answer 2

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

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

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

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

Answer 3

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

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