假设我有一个聚合，Ticket。ATicket将有一个分配Department和一个或多个分配Employee。
实例化 a 时Ticket，aTicketFactory是否应该负责确保 aTicket是使用有效/存在的Department和创建的Employee？
同样，在停用Departmentor时Employee，什么负责确保将新的DepartmentorEmployee分配给 aTicket以保持其不变量？域中是否存在负责退役的服务，或者这是应该采用最终一致性或某种形式的事件侦听的情况？
将TicketFactory声明为了创建 aTicket您需要同时引用 aDepartment和 an Employee。它不会验证那些确实存在。获取适当的引用将是调用代码的责任。
如果使用最终一致性，a 的退役Department将Employee发布指示退役的事件。将有一个与 a 相关联的处理程序，该处理程序Ticket将订阅该事件并分配新部门和员工或向任务发送某种警告。
查看有效的聚合设计以了解更多信息。
我最近开始探索 DDD，所以我遇到了你提到的一些问题。
我认为TicketFactory应该始终返回经过验证/正确构建Ticket的实例。如果您的模型很复杂，您可以拥有一个域服务来验证给定的Department或Employee可以附加到它，然后工厂使用它。否则，您可以将其全部放在工厂中。但是从工厂出来的应该是一张合适的票。
我会说，如果 eg 只Ticket知道其他两个，使用Department和Employeerepos 的域服务将完成工作。如果关系是双向的，那么您可以利用事件溯源。此外，如果它确实是一个应该在您的域模型中捕获的事件，并且除了重新洗牌票证之外还有其他后果，您可以将其中一个处理程序附加到该事件为InvalidTicketHandler. 但是如果它是一个小规模的东西，保持简单，只要有一个维护不变量的域服务。
旁注：如果Department和/或Employee本身是聚合，那么您可以Ticket通过它们的标识符（例如员工的公司 ID 或部门的 ID 代码）在其中引用它们。这样，您将更容易实现一致性，因为您不会跨越不同聚合之间的一致性边界。
FACTORY 负责确保它创建的对象或 AGGREGATE 满足所有不变量；但是，在删除应用于该对象之外的对象的规则之前，您应该始终三思而后行。FACTORY 可以将不变检查委托给产品，这通常是最好的。[领域驱动设计：解决软件核心的复杂性]
A 取决于问题类型，但从外观上看，它似乎是应用层功能的绝佳候选者，但我不会选择事件解决方案，因为我发现它只适用于层之间而不是同一对象之间层。