DDD：聚合根引用属于另一个聚合根的子实体答案

【问题标题】：DDD: Aggregate Root references child Entity that belongs to another Aggregate rootDDD：聚合根引用属于另一个聚合根的子实体
【发布时间】：2019-01-26 05:44:53
【问题描述】：

这是我要解决的问题。我有客户。该客户需要软件来管理事件。

客户有多个设施。每个FACILITY包含多个LOCATIONS。

当他们记录事件时，他们需要记录的最少信息是发生的LOCATION，的FACILITY地点发生的地点和发生的事情。

所以我有问题正在建模这个问题。这就是我所拥有的。

这是我的问题：我这是一个很好的设计。 FACILITY 根在 imo 中是有意义的，因为 LOCATION 不能单独存在。但 Incident 现在对 FACILITY 和 LOCATION 都有一个软引用。

我考虑让 LOCATION 成为值对象而不是实体。在这种情况下，INCIDENT 将拥有自己的 LOCATION 副本。但是，如果 LOCATION 发生变异，这将成为一个问题。

有什么想法吗？提前致谢。也许我错过了一些东西。仅作记录 - INCIDENTS 因为它们包含工作流等变得非常复杂并且是核心域。也许只有 INCIDENT 应该用 DDD 解决？

【问题讨论】：

标签： domain-driven-design

【解决方案1】：

好吧，如果位置发生变化，您确定要将更改传播到事件的位置吗？我想它改变的唯一原因是修复错别字，但这是你需要问的问题。

在任何情况下，您都可以引用复合 ID，我最常将其表示为 IncidentLocation 值对象。该规则仅规定您不能有对子实体的对象引用，并且您不能只引用子实体的 ID，因为它只能保证在其根中是唯一的。

请注意，这里至少有两个上下文可能是个好主意。管理设施和此类详细信息的基于 CRUD 的上下文，以及可以管理事件生命周期的事件日志记录上下文。在这种情况下，Location 可能是第一个上下文中的实体，而第二个上下文中的不可变值对象 Location {facilityId, locationId}。

【讨论】：

@MegaByte：如何位置会发生变异是一个重要的问题。考虑一个Order 和一个LineItem，它引用了一个ProductId，其中客户订购了5 支“红笔”。然而，有人发现这些笔实际上是蓝色，并将描述更改为“Blue Pens”。这极大地改变了顺序。这会导致相当多的混乱。你的位置改变也会发生同样的情况。错字没有问题，但可能会发生一些重大变化，这可能会导致 Incident 受到某种不利影响。
感谢您的回复。我喜欢 IncidentLocation 值对象/复合 id 方法。在我的情况下， locationId 是引擎盖下的 guid，所以它应该是唯一的。将 facilityId 作为复合键的一部分包含在内仍然是一个好主意/做法吗？
@MegaByte 好吧，首先为嵌套实体设置一个全局唯一标识符没有多大意义。似乎效率很低？不添加 facilityId 的危险在于您的模型变得依赖于子实体 ID 始终唯一的保证，而这不是常见 DDD 建模规则的限制。如果您必须从您的域中查找子实体，它也会感觉不那么自然（例如 findFacilityByLocation(locationId)）。