Hola!

As I had understood, only one aggregate could be modified and persisted to data store in a request.
However in Chapter 21, figures 21-15, 21-19 and 21-20 show an example where "order" and 'account' aggregates are modified in the same request.

Please, could you explain this behavior? Isn't a strong rule? Are there reasons to break the rule?

Thanks and congratulations for the book!
José.

Hi,

In my opinion it's a firm rule but not an absolute one. Sometimes it's best to save multiple aggregates in one transaction. But if you find yourself doing it a lot it can indicate that there are design issues with your model. It can also cause locking problems, where you are locking lots of database rows at once.

You're right about listing 21 - 15. However, this is an example where you really do have 2 aggregates being updated in the same transaction so support a genuine business policy.

We discussed these scenarios in a bit more detail in the aggregates chapter, chapter 19. Instead of saving 2 aggregates in the same transaction, we could have used asynchrony, but that would have introduced asynchrony.

Basically, sometimes its the best approach, but if you find yourself doing it a lot, I would recommend looking at your model and justifying each case.

Cheers