在第4章（第一个草图）的 4中在C＃中应用带有示例的域驱动设计的书中。并发冲突检测很重要我不明白为什么作者选择了这个聚合。客户有自己的聚合，而Order有自己的聚合。
我认为客户应该参考他的订单。
订单只与客户有身份。我没有看到一个情况是通过他的id从数据库获取订单。但是如果我应用这个逻辑，那么在我的域模型中，我几乎没有包含所有实体和值对象的复杂聚合。我不想要这个。
从数据库获取客户时，它不会直接加载他的订单（延迟加载）。所以这不是一个论点。
如果客户在不同的情况下使用，那么最好清除客户的参考仅在一种情况下有用。我想这是为订单汇总并对其订单进行“间接参考”的一个原因。
那么选择聚合的真正原因是什么？
我有另一个误解。订单有更多OrderLine。 OrderLine有一个产品。为什么允许OrderLine在聚合顺序之外引用对象（Product）？
答案 0 :(得分：8)
我认为客户应该参考他的订单。
与a repository look-up is an alternative to object references. 实现关系在客户和订单之间存在关系的这些类型的情况下，它很有用，但实现为对象引用没有意义。出于某些原因，这是如此。一个是加载与客户关联的所有订单可能是不可行的。即使使用延迟加载，您通常也需要一个分页集合。另一个原因是作者所称的并发冲突检测，也称为事务一致性。没有涉及与客户相关的所有订单的任何行为，并且引用所有订单是不必要的。
从数据库获取客户时，不会直接加载他的客户 订单（延迟加载）。所以这不是一个论点。
延迟加载can be problematic。主要原因是难以实现，缺乏实施的灵活性以及降低推理代码的能力。
那么选择聚合的真正原因是什么？
聚合应该是一致性边界。换句话说，聚合界定了一组实体和值对象，这些实体和值对象必须在与聚合相对应的行为下保持一致。这既有业务上的影响，也有技术上的影响。有关详细信息，请查看Effective Aggregate Design。
为什么允许OrderLine具有对象的引用 （产品）外部汇总订单？
通常，订单行应引用表示订购产品的值对象，而不是对实际产品实体的引用。这部分是由于讨论的聚合约束，也是因为订单是一个事件，应该是不可变的。