Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

DDD - persisting aggregate children only if changed

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?

like image 862
Kanstantsin K. Avatar asked Dec 09 '15 10:12

Kanstantsin K.


1 Answers

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.

like image 179
theDmi Avatar answered Sep 19 '22 16:09

theDmi