In book 通过 C# 示例应用领域驱动设计 in 第4章（第一个草图）在点上4.并发冲突检测很重要我不明白为什么作者选择这个聚合。客户有他自己的聚合，订单有他自己的聚合。
我认为客户应该参考他的订单。
订单仅与客户相关。我没有看到任何一种情况可以通过他的 ID 从数据库获取订单。但是，如果我应用此逻辑，那么在我的域模型中，我几乎没有包含所有实体和值对象的复杂聚合。我不想要这个。
当从数据库中获取客户时，它不会直接加载他的订单（延迟加载）。所以这不是一个论点。
如果客户在不同的场景中使用，那么最好清除客户，因为该参考仅在一种场景中有用。我想这是对订单进行聚合并对他的订单进行“间接引用”的原因之一。
那么选择聚合的真正原因是什么？
我还有一个误会。订单有更多 OrderLine。 OrderLine 有一种产品。为什么允许 OrderLine 引用聚合订单之外的对象（产品）？
我认为客户应该参考他的订单。
建立与存储库查找是对象引用的替代方法。 http://gorodinski.com/blog/2012/07/24/implementing-associations-with-references-or-repositories-in-domain-driven-design-ddd/它在客户和订单之间存在关系的此类情况下很有用，但作为对象引用实现没有意义。之所以如此，有几个原因。一是加载与客户相关的所有订单可能不可行。即使使用延迟加载，您通常也需要一个分页集合。另一个原因是作者所说的并发冲突检测，也称为事务一致性。不存在任何涉及与客户关联的所有订单的行为，并且无需引用所有订单。
当从数据库中获取客户时，它不会直接加载他的
订单（延迟加载）。所以这不是一个论点。
延迟加载可能有问题 http://gorodinski.com/blog/2012/06/16/orm-lazy-loading-pitfalls/。主要原因是实现困难、缺乏灵活性以及代码推理能力的降低。
那么选择聚合的真正原因是什么？
聚合应该是一致性边界。换句话说，聚合界定了一组实体和值对象，这些实体和值对象在与聚合相对应的行为下必须保持一致。这具有业务和技术方面的影响。看一眼有效的总体设计 https://vaughnvernon.co/?p=139了解更多相关信息。
为什么允许 OrderLine 拥有对对象的引用
（产品）外部总订单？
通常，订单行应引用代表订购产品的值对象，而不是对实际产品实体的引用。这部分是由于所讨论的聚合约束，但也因为订单是一个事件并且应该是不可变的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
