CODEWITHSUNDEEP
transactionsdomain-driven-design
Anton Putov
Anton Putov

Reputation: 1981

Transaction involves several aggregate roots

How can I deal with transactions that involve several aggregate roots? Imaginane we have domain service which perfom some bank transaction between two accounts.

      aggregateRoot1 = Repository.getById(id1);

      aggregateRoot2 = Repository.getById(id2);

      aggregateRoot1.increaseAmount(sum); //first transaction

      aggregateRoot2.decreaseAmount(sum); //second transaction

How can I handle case when electricity fails after first transaction or something like this? I am new in DDD (DDD + CQRS+ EventSourcing) and just looking for all benefits and weak sides of such design approach. Thanks.

Upvotes: 0

Views: 154

Answers (1)

Codescribler
Codescribler

Reputation: 2305

Thats an interesting question as it reveals 2 interesting things about DDD + CQRS + EventSourcing.

The first, at face value the way to manage this process is with a process manager that can track the success or otherwise of the process and therefore knows when and how to persist the result. This manager can ensure that it manages the 'transaction' and it can ensure it all passes or it all fails.

The second part is the methods themselves. A key benefit of CQRS and an important driver for using DDD is that you end up with a 'ubiquitous language' for your system. IncreaseAmount doesn't say 'why' the amount is being increased. Is it a transfer between accounts owned by the same person or a payment being made or is it a charge being levied.... So to recap, a key strength of DDD and one that almost happens by default for in CQRS is that you end up with a language that you and non-techy business people with domain knowledge can understand and reason about. This is a very powerful and important benefit of DDD in general and CQRS specifically.

Not sure if this really answered your question but I hope if gives you some food for thought.

Upvotes: 1

Related Questions