Question

There is something not clear to me about domain-driven-design and unit of work pattern.
Let’s say I have an entity that was retrieved from a repository. Once I updated this entity, how UnitOfWork should know that it was updated, so the updated entity can be persisted to the DB?
Currently, I see two options:

1) Manually call uow.Update(entity) in the service layer. E.g.:

Employee emp = EmployeeRepository.GetByID(1);
emp.Name = "NewName";
uow.Update(emp);
uow.Commit();

2) Rely on some ORM magic to track changes, and persist updated entities to the DB. E.g.:

Employee emp = EmployeeRepository.GetByID(1);
emp.Name = "NewName";
uow.Commit();

Both these options seems hairy to me:
First – if changes were made inside some aggregate, the aggregate should let the service layer know that it updated some entities.
Second – isn’t relying on ORM implementation is violation of Persistence Ignorance principle?

What do you do in your projects? Or maybe I miss something / messed up something and there is better solution?

Thanks

Answer 1

First: Why does the aggregate have to let anyone know that it updated some entities? If you’re using ‘Repository per Aggregate Root’ and a proper ORM that will persist your entire graph you can do something like this..

Employee emp = employeeRepository.GetById(1);

emp.RewardWith(new GoldStar());

employeeRepository.Save(emp);

Any half decent ORM will be tracking the entire employee graph so it will know that the employees star chart has been modified and persist changes accordingly.

Second: your domain needs to be persistence ignorant.. it is very important that developers working with the system not be 🙂