How to choose DDD Aggregate?

Question

In book Applying Domain-Driven Design With Examples in C# in Chapter 4 (A first Sketch) on point 4. Concurrency Conflict Detection Is Important i don't understand why the author has choose this aggregates.Customer has his own aggregate and Order has his own aggregate.

I think Customer should have a reference to his orders.

Order have identity only with a customer. I'm not see one situation to get an order from database by his id. But if I apply this logic then, in my domain model, I have few complex aggregates that contain all of my entities and values objects. I don't want this.

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

If customer is used in different scenarios then it's better to clear customer for that references only useful in one scenario. I guess that this is one reason for make an aggregate for order and have an "indirect reference" to his orders.

So what are the real reasons for choosing an aggregate?

I have another misunderstanding. Order has more OrderLine. OrderLine has one product. Why is permitted as OrderLine to have a reference to an object (Product) outside aggregate order?

Answer 1

I think Customer should have a reference to his orders.

Implementing a relationship with a repository look-up is an alternative to object references. It is useful in these types of situations where there is a relationship between a customer and an order, but it doesn't make sense to implement as object reference. This is so for a few reasons. One is that it may not be feasible to load all orders associated with the customer. Even if lazy loading is used, you typically will want a paginated collection. Another reason is what the author refers to as concurrency conflict detection, which is also referred to as transactional consistency. There aren't any behaviors which involve all orders associated with a customer and referencing all orders is needless.

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

Lazy loading can be problematic. The main reasons are difficultly and lack of flexibility in implementation as well as a reduction in the ability to reason about code.

So what are the real reasons for choosing an aggregate?

An aggregate should be a consistency boundary. In other words, an aggregate delimits a set of entities and value objects which must remain consistent under behaviors corresponding to the aggregate. This has both business and technical ramifications. Take a look at Effective Aggregate Design for more on this.

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

Typically, an order line should reference a value object representing the ordered product, not a reference to the actual product entity. This is due in part to aggregate constraints discussed, but also because an order is an event and should be immutable.