集合体之间的关联，如何决定是保留对对象的引用还是仅对对象的标识

Question

举例来说，一场演出有多个表演者...

第一个选项：

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

第二个选项：

Performance
+PerformerIds[]

第一个选项优点：

• 出于查询目的而更易于访问（让我说我不想使用CQRS）
• 当我们查看域模型时，它似乎更容易理解，性能与表现者之间的关系更加明显

第一个选项缺点：

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

第二个选项的优缺点显然与第一个选项相反，从性能上更难访问执行者，更难以理解模型图，减轻负载并减少耦合。

我有点像第一个选项，因为Performance对象不可能使用Performer对象。该关系更像是数据关系/查询模型。 但我认为，这也会使域模型图变得不太清晰，因此我不确定是否应该使用哪种解决方案。

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

Answer 1

  

如何决定是保留对对象的引用还是仅保留对对象的身份

保留对相关聚合根（AR）身份的引用，即可明确其边界。

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

• 如果您拥有对相关聚合根（AR）的引用，则很容易跨越它们之间的界限。
• 同时更改几个聚合非常容易，尤其是在使用ORM或已实现工作单元的情况下。因此，您的聚合根不再是事务边界。
• 如果仅保留相关聚合根（AR）的标识符，则要访问相关AR，必须先从存储库中加载它。这是一个权衡。当您跨过一个集合的边界并查询另一集合时，它变得非常明确。

  

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

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

如果您的所有“聚合根”都很小，并且您使用的ORM免费提供很多魔术功能（请注意：总会有价），并且在类关系图上看到引用的价值大于看到的价值。边界，然后尝试保留对相关AR的引用，即使您的代码确实不需要它也是如此。

然后评估您的模型。