Domain driven design child entities change tracking

Question

I'm having some difficulty figuring out how the Aggregate Root will track changes on child entities.

Let say I have an aggregate:

• Order (root)
• OrderLineItem

With the Order class being the aggregate root. How will I track the changes made on each of the OrderLineItem through the Order class?

When I make a repository (implementing) e.g. an OrderRepository (because only the aggregate root can have the repository right?), how will my OrderRepository track the changes of each OrderLineItem?

Example:

• Newly added but not committed to DB
• Edited but committed to DB
• Edited but not committed to DB

How do you guys deal with this?

Answer 1

with the Order class being the aggregate root now how will I track the changes made on each of the OrderLineItem through the Order class?

All changes to the Order aggregate, including OrderLineItem, should go through the aggregate root. This way, the aggregate can maintain its integrity. As far as tracking changes, that depends on your persistence implementation. If using an ORM such as EF or NHibernate, then the ORM will take care of tracking changes. If using event sourcing, then changes are tracked explicitly as a sequence of events, usually maintained by the aggregate in OOP implementations. If using SQL directly, you can also avoid tracking changes and update the entire aggregate upon each commit.

and when I make a repository(implementing) say OrderRepository because only the aggregate root can have the repository right?

Yes, repository per aggregate.