domain-driven-design - 聚合之间的关联，如何决定是持有对对象的引用还是仅持有其标识

Question

例如，给一个有多个表演者的表演......

第一个选项：

Performance (1) ---> (*) Performer

第二种选择：

Performance
+PerformerIds[]

第一种选择优点：

• 更轻松地访问查询目的（假设我不想使用 CQRS）
• 当我们查看领域模型时似乎更容易理解，Performance 和 Performer 之间的关系更加明显

第一个选项缺点：

• Performance 对象的加载较重（可以通过延迟加载来修复）
• 更多耦合

第二个选项的利弊显然与第一个选项相反，更难从性能中获得表演者，模型图更难理解，负载更轻，耦合更少。

我有点喜欢第一个选项，因为 Performance 对象永远不会使用 Performer 对象。这种关系更像是数据关系/查询模型。但在我看来，它也使域模型图不太清晰，所以我不确定我是否应该使用哪种解决方案。

我的问题可能是我试图为领域专家和开发人员使用相同的类图吗？和/或建模主要用于查询而不是更新？

标签： domain-driven-designaggregateaggregateroot

Answer 1

如何决定是持有对对象的引用还是仅持有其身份

持有对相关聚合根 (AR) 身份的引用使其边界明确。

当然，每个 AR 仍然拥有对其所有实体的引用，但无论您引用聚合根还是实体，它在您的域模型中都变得非常明确。

• 如果您持有对相关聚合根 (AR) 的引用，则很容易跨越它们之间的界限。
• 同时更改几个聚合非常容易，特别是如果您使用 ORM 或实施了工作单元。因此，您的聚合根不再是事务边界。
• 如果您只持有相关聚合根 (AR) 的标识符，为了访问相关的 AR，您必须先从存储库加载它。这是一个权衡。当您跨越一个聚合的边界并查询另一个聚合时，它变得非常明确。

我不喜欢的是，当您查看类图时，您所看到的只是它们之间没有任何关联的单独聚合，这对于显示相关的域概念看起来不是很有用。

您的域模型是一个“模型”，由您来做出设计决策。

如果你所有的聚合根都很小，并且你使用了一个免费做很多魔法的 ORM（注意：总是有代价的），并且在类图上看到引用的价值大于看到边界的价值，然后尝试持有对相关 AR 的引用，即使您的代码并不真正需要它。

然后在一段时间内评估您的模型。