Geek Answers Handbook

DDD: persistent aggregates

Consider a typical example of Order and OrderItem . Assuming OrderItem is part of the Order aggregate , it is added only through Order. So, in order to add a new OrderItem to the Order , we need to load the entire Aggregate through the repository, add a new element to the Order object and save the entire Unit again.

It seems to have a lot of overhead. What if our Order has 10 OrderItems ? Thus, just to add a new OrderItem , we not only have to read 10 OrderItems , but we also have to re-insert all these 10 OrderItems again. (This is the approach that Jimmy Nillson took in his DDD book. Each time he wants to save the aggregate, he clears all the child objects and then reinserts them again. This can cause other problems, because the identifier of the children is changed every time due to IDENTITY column in the database.)

I know that some people may propose applying the Unit of Work template to Aggregate so that it tracks what has been changed and only record these changes. But this violates the Persistence Notorance (PI) principle, because the logic of stability flows in the domain model.

Has anyone thought of this before?

Mosh

+5
source share
3 answers

This should not be a problem; some ORMs support lazy lists. for example, you can load an order object and add elements to the Details assembly without actually materializing all the other objects in this list.

I think N / Hibernate supports this.

ORM, , , ORMappers, .

+1

, DDD , . , . , 100 000 , () . , , . , . , - .

+1

100% , , . , , / , . / UoW ( UoW )

:

, -, . , , , .

+1

More articles:


All Articles