c# - 如何选择DDD聚合？

Question

在 Applying Domain-Driven Design With Examples in C# 的第 4 章(第一个草图) 中第 4 点。并发冲突检测很重要我不明白为什么作者选择这个聚合。客户有他自己的聚合，订单有他自己的聚合。

我认为客户应该引用他的订单。

订单只对一个客户有身份。我没有看到一种情况可以通过他的 ID 从数据库中获取订单。但是，如果我应用此逻辑，那么在我的域模型中，我几乎没有包含所有实体和值对象的复杂聚合。我不想要这个。

当从数据库中获取客户时，它不会直接加载他的订单(延迟加载)。所以这不是争论。

如果 customer 在不同的场景中使用，那么最好清除 customer 以确保仅在一种场景中有用。我想这是对订单进行汇总并“间接引用”他的订单的原因之一。

那么选择聚合的真正原因是什么？

我还有一个误会。 Order 有更多的 OrderLine。 OrderLine 有一种产品。为什么允许 OrderLine 引用聚合订单之外的对象(产品)？

Answer 1

I think Customer should have a reference to his orders.

实现与 a repository look-up is an alternative to object references. 的关系它在客户和订单之间存在关系的这些类型的情况下很有用，但作为对象引用实现没有意义。之所以如此，有几个原因。一是加载与客户关联的所有订单可能不可行。即使使用延迟加载，您通常也需要一个分页集合。另一个原因是作者所说的并发冲突检测，也称为事务一致性。没有任何行为涉及与客户关联的所有订单，因此无需引用所有订单。

When get a customer from the database it will not load directly his orders (Lazy Loading). So this is not an argument.

延迟加载 can be problematic .主要原因是实现难度大、灵 active 差，代码推理能力下降。

So what are the real reasons for choosing an aggregate?

聚合应该是一个一致性边界。换句话说，聚合界定了一组实体和值对象，这些实体和值对象必须在聚合对应的行为下保持一致。这既有商业上的影响，也有技术上的影响。看看Effective Aggregate Design有关更多信息。

Why is permitted as OrderLine to have a reference to an object (Product) outside aggregate order?

通常，订单行应该引用表示订购产品的值对象，而不是对实际产品实体的引用。这部分是由于讨论的聚合约束，但也因为订单是一个事件，应该是不可变的。