DDD - persisting aggregate children only if changed
Asked Answered
B

1

9

I'm trying use DDD in an application I'm currently working on. I have a following UserAggregate structure:

UserAggregate
- ProfileEntity
- ImageEntity
- RatingEntity

And i have a UserRepository which is querying entities mappers to build a UserAggregate.

Now I'd like to pass the UserAggregate to the UserRepository for persistance, like UserRepository->save(UserAggregate). How do I tell the UserRepository that UserAggregate children entities have changed and needs to be saved? Is there any common pattern for that? I'm aware of UintOfWork pattern but can't really imagine how it may help with children, as I'd like to hit the mappers (and the database) only if the children entities are actually changed.

Is there any way to track a "dirty state" of the entity object, specifically in PHP? Or Am I missed the concept of aggregate roots and repositories?

Biggers answered 9/12, 2015 at 10:22 Comment(0)
C
9

There are basically two approaches to that problem. You can either use snapshot comparison or proxy-based change tracking. Both of them have advantages and disadvantages. Selection also depends on the libraries you use, as they may have support for one of them.

Here, I describe the basic approaches. I don't know what libraries you're using exactly, so this will help you select a strategy and evaluate libraries.

Basic Design Considerations

Both strategies are a responsibility of the persistence mechanism and MUST NOT leak into the domain and application logic. In other words, they must be transparent to the users of the repository and to domain objects.

Snapshot Comparison

With this strategy, you keep a snapshot of the aggregate data when the aggregate is loaded through the repository. Later, when the potentially modified aggregate is passed in an Update call to the repository again, you walk the aggregate to determine whether data in it changed or not.

Proxy-based Change Tracking

With this strategy, you return an object that proxies the real aggregate instead of the aggregate itself. The proxy is created and used to wrap the aggregate when the aggregate is loaded through the repository.

The proxy does nothing on read operations on the aggregate, but sets a dirty flag whenever a mutating operation is invoked. When the (proxied) aggregate is passed to the repository for persisting, you simply check the dirty flag.

Contributor answered 9/12, 2015 at 11:9 Comment(3)
thank you! I was thinking about tracking the state inside each entity, but proxy-based approach seems much more clear.Biggers
Doing this within the entity is not a good idea because of the points I mention under "basic design considerations" - persistence concerns would leak into the domain layer if you did that.Contributor
Thanks for the answer. These two strategies are both offered by Entity Framework so I can easily relate to.Anallise

© 2022 - 2024 — McMap. All rights reserved.