A basic question on DDD aggregates order and payment

Question

There's is a statement from https://martinfowler.com/bliki/DDD_Aggregate.html:

An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole.

What I have Order that has Items, and those items may be paid with different payments.

Should Include payments entities into the Order Aggregate, because otherwise it actually should have a link to inner Order's Item, not the whole Order? I don't get a little this Aggregate rule, and how it should be applied in the case.

My question: What Aggregates may exist in this case, can there be separate OrderAggregate, and say some other Aggregate that holds payments entities?

Answer 1

In DDD Agreegate Root objects or ARs are supposed to group together all the data that is significant to the calculations you need to make in your business logic.

So in your order and items example. If you need to calculate the shipping cost of an order by adding up the weight of each item then you should have Order.Items which contains all the items in an order.

If any single item changes the the overall order changes. So they should all be dealt with together as a single thing.

Obviously there is a danger here in that I could have a business rule. The Business' value is the sum of all its customers, orders, items, prices minus the sum of all its employees, years, months, paychecks.

If you try to put everything in a single aggregate root it doesnt work.

If two programs change the same AR at the same time you have a problem. effectivly a merge needs to be done.

If you cant hold the whole AR in memory then you have to buy a more expensive computer.

The bigger your ARs get the more of these problems you have.