I'm trying to wrap my head around the best possible solution in the following situation:
When updating part of an aggregate, could be any part of the aggregate so either the root or any other entity, how could these changes be persisted back to the db layer.
There have been a lot of solutions on StackExchange advising something like using your ORM models as Domain objects so you could change the attribute on the Aggregate and let the ORM layer diff and flush the changes to the db, most examples contain references to the Enity Framework if I'm not mistaken. Like the solution here, Article which is a Domain object contains ORM persistence logic
My partial understanding of DDD was that you shouldn't define any persistence layer logic in your domain models. The persistence logic should be defined in your repository, possibility of having a variety of persistence mechanisms (Postgres, MongoDB, S3 etc). Also 'littering' Domain models with persistance logic and/or 'original' SQL objects makes it a lot harder to test my Domain objects / Aggregates.
I'm having trouble understanding an easy and simple solution, maybe there isn't any, on how to map these changes back to my ORM layer, in my case I'm using Postgres. Unless the answer is a strong mapping between your ORM model and Domain model in your repository it looks really hard and verbose to do so.
I figured out, by reading other solutions, that there are a couple of other possibilities (they all have their own drawbacks):
ModelAttributeChangedevent whenever you change something in your Domain model. You could either return this event, or store it somewhere on the Domain model. When persisting this model in the repository, query the ORM model first and map these changes back on the ORM model before committing it.
changed_name_event = person_aggregate.set_name('Henk') Repository.save(person_aggregate, changed_name_event)
After you change something on the Aggregate, explicitly call the update method on the Repository aswell to update the attribute. You'd need to update everything on both the Aggregate and on the repository, and you need to know in advance which attributes of your aggregate are going to change before calling the right method on your repository.
person_aggregate.change_name('Henk') repository.change_person_name(person_aggregate, 'Henk')
Ideally I just want to be able to update my aggregate and save it through my repository. However because I map my ORM model to an AR, Aggregate Root, I 'loose' the mapping to the ORM model. I could ofcourse keep track of all the changes I make to the Aggregate and whenever I call the repository apply these changes to the ORM model and commit it to the database. My 'problem' with this solution is that I need a strong mapping and tracking changes for nested entities is a hard, complex and error prone process.
If this is the necessary evil in order completely isolate your domain logic I'm okay with it but it just feels like a lot of logic has to be defined in order to get this abstraction working.