复制聚合：为什么我们不应该复制存在于聚合边界之外的对象？答案

【问题标题】：Copying Aggregate: Why shouldn't we also copy objects existing outside the Aggregate boundary?复制聚合：为什么我们不应该复制存在于聚合边界之外的对象？
【发布时间】：2016-02-24 00:27:26
【问题描述】：

当应用程序想要基于已经存在的 Aggregate 创建新的 Aggregate 时，我们可以将现有 Aggregate 中的所有内容（除了内部实体的 ID）复制到新的 Aggregate 中。但是如果某些内部对象引用了聚合边界之外的对象，我们就不能同时复制被引用的对象。

a) 我知道 Aggregate 应该管好自己的事，不要干扰其他 Aggregate 的生命周期，但如果我们也复制存在于 Aggregate 边界之外的对象，究竟会出现什么问题？

【问题讨论】：

你能提供一个更具体的例子吗？
@eulerfx：不管我们拥有什么样的领域模型，这不是一般规则吗（至少我是这样理解 DDD：Tackling Complexity 的作者的...... - 他从未明确说过它，但我认为他暗示它）？
我问的原因是从您的域中收集一些可能会影响答案的内容。 DDD 中并未明确涵盖复制聚合的内容，因此您的情况可能需要注意。
您当然可以将引用复制到外部对象，因为这些只是引用，不会影响聚合的事务完整性。然而有趣的是复制的原因。
它可能会影响复制对象的完整性，具体取决于该对象是什么。这就是为什么复制的性质很重要 - 这取决于复制的内容和原因。

标签： domain-driven-design

【解决方案1】：

假设您有一个聚合 Order 和一组 OrderLine 对象，并且您想基于现有订单创建一个新订单，您只需复制订单及其关联的订单行。即使订单行可能引用了Product，您也不会复制该产品，因为它不是聚合的一部分。

理想情况下，订单行甚至不应该包含对产品实例的引用，而应该只保留产品 ID。

正如 eulerfx 提到的复制背后的原因可能会提供更多见解:)

【讨论】：

“理想情况下，订单行甚至不应该包含对产品实例的引用，而应该只包含产品 ID。”我知道聚合应该确保在它自己的聚合中没有违反一致性规则，但是您如何认为引用产品可能会以某种方式违反聚合的任何一致性规则？
引用产品并不会破坏一致性规则，而是要创建一个具有明确定义边缘的非常独特的 AR。事实上，为了保持一致性，需要在订单行上有某种产品/服务。
“事实上，为了保持一致性，需要在订单行上拥有某种产品/服务。”您能否详细说明为什么需要将产品放在订单行以保持一致性？
...订单行通常定义为具有数量和可能附加数据的产品。因此，要使订单行保持一致，它必须引用产品 - 否则没有指向它。