Where would you typically implement transaction logic in domain-driven design?

Question

• In the consumer code? (like a controller)
• In repositories?
• In services?

Answer 1

For starters, that's a pretty controversial question, so you are bound to get many different answers.

My own take on this is that (ACID) transactions are a feature of certain storage mechanisms (most notably relational databases), so I consider the concept technology-specific. Before anyone protests that this is only a theoretical argument consider that there are several conceivable cases where the data store (Repositories) would not be transactional:

• Many large-scale enterprise (such as e.g. Amazon) don't use transactions for performance reasons. Instead, they have an architecture that enables them to deal with failures
• REST-based data services
• Test Doubles

Since Domain Models should be decoupled from specific implementations, I find it logical that they know nothing about transactions. However, this also means that the Repositories must expose operations of the right granularity so that they, themselves, can manage transactions, should they so desire, and an operation is guaranteed to either success or fail in its entirety.

In other words, Repositories should manage transactions (if applicable).

---

There are, however, situations where this may require the Repositories to have too much Domain knowledge, so the Unit of Work design pattern provides a good abstraction for the cases where you truly need a (potential) transaction to span multiple operations on several different Repositories.