如何选择DDD聚合
本文关键字：DDD 聚合 选择 何选择 | 更新日期: 2023-09-27 18:12:25
在第4章(第一个草图)关于4点的一书中。并发冲突检测很重要我不明白为什么作者选择这个聚合。客户有他自己的聚合，订单有他自己的聚合。
我认为客户应该有他的订单参考。
订单只与客户有标识。我还没见过通过他的id从数据库中获取订单的情况。但是，如果我应用这种逻辑，那么，在我的领域模型中，我有几个包含所有实体和值对象的复杂聚合。我不想要这个
当从数据库中获取客户时，它不会直接加载他的订单(延迟加载)。所以这不是一个参数
如果customer在不同的场景中使用，那么最好清除只在一个场景中有用的引用的customer。我想这是一个为订单做汇总并"间接引用"他的订单的原因。
那么选择聚合的真正原因是什么呢?
我还有一个误解。Order有更多的OrderLine。OrderLine有一个产品。为什么允许OrderLine在聚合订单之外有对对象(Product)的引用?
我认为客户应该有他的订单参考。
使用存储库查找实现关系是对象引用的另一种选择。在客户和订单之间存在关系的情况下，它很有用，但是作为对象引用来实现是没有意义的。这是有几个原因的。其一是加载与客户关联的所有订单可能不可行。即使使用了延迟加载，通常也需要一个分页集合。另一个原因是作者所说的并发冲突检测，也称为事务一致性。没有任何行为涉及与客户关联的所有订单，并且没有必要引用所有订单。
当从数据库中获取客户时，它不会直接加载他的订单(延迟加载)。所以这不是一个参数
延迟加载可能会有问题。其主要原因是实现困难和缺乏灵活性，以及对代码推理能力的降低。
那么选择聚合的真正原因是什么呢?
聚合应该是一个一致性边界。换句话说，聚合划分了一组实体和值对象，这些实体和值对象在与聚合对应的行为下必须保持一致。这对业务和技术都有影响。有关这方面的更多信息，请参阅Effective Aggregate Design。
为什么被允许作为OrderLine有一个对象的引用(产品)总订单外?
通常，订单行应该引用表示订购产品的值对象，而不是对实际产品实体的引用。这部分是由于讨论的聚合约束，但也因为订单是一个事件，应该是不可变的。