在第 4 章（第一个草图）中的第 4 章（第一个草图）中用 C#中的示例应用领域驱动设计一书中。并发冲突检测很重要我不明白为什么作者选择了这个聚合。客户有他自己的聚合，订单有他的聚合自己的聚合体。
我认为客户应该参考他的订单。
订单仅与客户具有身份。我没有看到通过他的身份从数据库中获取订单的情况。但是如果我应用这个逻辑，那么在我的域模型中，我几乎没有包含我所有的实体和值对象的复杂聚合。我不想要这个。
当从数据库中获取客户时，它不会直接加载他的订单（延迟加载）。所以这不是论据。
如果客户在不同的场景中使用，那么最好清除客户，因为该引用仅在一种场景中有用。我想这是对订单进行汇总并对他的订单进行“间接引用”的原因之一。
那么选择聚合的真正原因是什么？
我还有一个误会。Order 有更多的 OrderLine。OrderLine 有一种产品。为什么允许 OrderLine 引用聚合订单之外的对象（产品）？
我认为客户应该参考他的订单。
使用存储库查找实现关系是对象引用的替代方法。在客户和订单之间存在关系的这些类型的情况下，它很有用，但作为对象引用实现没有意义。之所以如此，有几个原因。一是加载与客户相关的所有订单可能不可行。即使使用延迟加载，您通常也需要分页集合。另一个原因是作者所说的并发冲突检测，也称为事务一致性。没有任何行为涉及与客户关联的所有订单，并且没有必要引用所有订单。
当从数据库中获取客户时，它不会直接加载他的订单（延迟加载）。所以这不是论据。
延迟加载可能会出现问题。主要原因是实施难度大、缺乏灵活性，以及推理代码的能力下降。
那么选择聚合的真正原因是什么？
聚合应该是一致性边界。换言之，聚合界定了一组实体和值对象，这些实体和值对象在对应于聚合的行为下必须保持一致。这既有商业影响，也有技术影响。查看有效的聚合设计以了解更多信息。
为什么允许 OrderLine 引用聚合订单之外的对象（产品）？
通常，订单行应该引用代表订购产品的值对象，而不是对实际产品实体的引用。这部分是由于所讨论的聚合约束，但也因为订单是一个事件并且应该是不可变的。