Search code examples
transactionsdomain-driven-design

Implementing Domain-Driven Design and Transactions


I am confused about at least one thing after reading Vaughn Vernon's Implementing Domain-Driven Design. In Chapter 12 Repositories he says that transactions are managed in the application layer. But he also says that an aggregate is synonymous with transactional consistency boundary. And since repositories provide global access to aggregates, why couldn't transactions be managed in repositories? Is it because the rule aggregate == transactional consistency boundary is only a rule of thumb that must sometimes be broken, or is there something else to it?


Solution

  • why couldn't transactions be managed in repositories?

    Because a Repository isn't an abstraction for "a business transaction", a Repository is an abstraction for "a collection of domain objects that you can take from or add to".

    By definition, a transaction has a beginning and an end. It is a process. A Repository isn't. The relationship between Transaction and Repository is not is-a, it's has-a. The transaction uses its repository.

    When we say that Aggregate should be the consistency boundary, we mean that it should be the only block of state encompassed by a transaction, not that an Aggregate should be the same thing as a transaction.