Question

Inside every aggregate the consistence must be guaranteed. It is easy to do it in the repository because I can always use transactions from the database or framework. I have doubts about what happens outside the repository. A service might need to work with more than one aggregate to process a request. There could be problems during the processing in the service or while the aggregates are persisted.

If something goes wrong during the processing in the service I could raise an exception. That way the operation will be atomic. This is my first concern. Is that a good practice? The problem I see is that it will be hard to recover from that. There will be no easy way to leave all the aggregates with the state they had before the failed operation.

The other problem I have is what happens if one of the aggregates fails to be persisted. How do I ensure the consistency of the information? Do I have to use database transactions outside the repositories? I was thinking that it might not be the best solution because I should not be thinking in the database when I am designing the domain model.

Answer 1

The solution to this is provided in the Unit of Work pattern – http://martinfowler.com/eaaCatalog/unitOfWork.html

You can encapsulate as many aggregate root operations into a single UOW as you want. The unit of work concrete implementation can then contain its own commit and rollback logic, specific to the persistence method and technologies involved. For example, you deal with the TransactionScope object ( http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope.aspx) if you were working in .NET.

Here is a decent article on how to implement a basic UOW pattern – http://msdn.microsoft.com/en-us/magazine/dd882510.aspx