Avoid updating multiple Aggregates in Library Application

Question

I am currently analysing the project ddd-library which is really helping in learning designing a system based on DDD principles. However there is one thing I have a problem with.

In case of placing a book on hold, first the Patron Aggregate is updated (it holds now a book) and then the Book Aggregate is updated. Whether it is an atomic transaction or eventual consistent, in both cases it is kind of problematic.

Atomic Transaction: Obviously we shouldn't modify 2 Aggregates in one transaction so there is that, but I dont think it would come with any other problems here (Maybe one could live with breaking the 'one aggregate modification per transaction' rule?)

Eventual Consistent: When the Patron is updated first and now 'holds' the book but the book Aggregate is not updated yet to become a BookOnHold, there might be a race condition when someone else at the same time tries to put it on hold. That patron aggregate would be updated and maybe its event is propagated first to the Book Aggregate. In this case the system would be in an invalid state, because the first Patron has a book on hold but the actual Book Aggregate is being hold by the second Patron.

Question: How would you solve this? Is there a better way to model the Aggregates? Is a Process Manager or Saga an appropiate Solution here?

Suggestions (Saga/Process Manager): It would start when the patron aggregate was updated. When after some time the referenced Book isn't updated, it could revert the Patron modification and raise some domain events to handle the case. So that way the eventual consistency solution wouldn't run into the problem I stated right? Or am I overthinking here or missing something?

Answer 1

The premise ‘we shouldn't modify 2 Aggregates in one transaction’ is false. As this answer states it's a consideration rather than a rule. It could also be an indication that the aggregate boundaries are not modelled correctly.

A more important principle is that a command shouldn’t invoke methods on multiple aggregates.

However, if a single method is invoked and that method raises a domain event, methods on other aggregates could be invoked by in-memory event handlers.

All of these in-memory changes can be wrapped in a single transaction when persisting the data.

Answer 2

Note: this answer focuses specifically on "designing a system based on DDD principles" as you pointed out that this is your goal. I'm sidestepping ancillary considerations that DDD itself does not focus on.

TL;DR
When dealing with things like DDD, it's very important to understand the cause-and-effect relationship of what drives your design, and you have to take great care to no end up making domain design decisions for reasons that are in fact unrelated to the domain. Your current concern about database transaction is one such example of an unrelated concern.

---

Be careful about the ambiguity of the word "transaction", and how you express your needs about how you expect your transactions to work.

Domain aggregates are indeed independent items whose logic does not depend on the logic (or outcome) of another aggregate. But this is a design consideration for your domain.

When you use "transaction" to refer to a single command requiring two subsequent changes to two different aggregates in your domain logic, you are correct that we should avoid these at all costs.

But that's not the same as what a "transaction" is to your persistence mechanism. While it still fits the general bill of an "all or nothing" bundle of operations, this is not a domain consideration; it's a technical implementation detail of your persistence mechanism. Very intentionally, the domain does not and should not care about how the persistence mechanism works.

Similarly, the domain does not and should not care about how the surrounding application itself works. It merely defines how an aggregate operates. The domain does not get a say in whether the application chooses to orchestrate several individual domain operations, for whatever reason it chooses to do so.

As far as DDD is concerned, the only thing that needs to be independent is the actual command executed on your aggregate. DDD does not prescribe whether an application is allowed to call several of these independent commands, nor whether the underlying persistence mechanism chooses (or is allowed to choose) to employ a methodology to not allow for partial persistence (i.e. by using a database transaction).

When dealing with things like DDD, it's very important to understand the cause-and-effect relationship of what drives your design, and you have to take great care to no end up making domain design decisions for reasons that are in fact unrelated to the domain. Your current concern about database transaction is one such example of an unrelated concern.