Transaction boundaries

[Andrew Easter]

I've been reading the new DDD book Patterns, Principles & Practices of Domain-Driven Design and there's a section of the book on Application Services that I find to be a little conflicting with regard transaction boundaries.

My general understanding has been that an Aggregate represents a transactional boundary. However, in the aforementioned book, it encourages the use of transactions to update multiple aggregates within an Application Service. The motivation for doing this is to deal with situations where a business rule spans multiple aggregates and thus a rollback should be triggered if any one update fails.

I'm not sure I feel too comfortable about this approach.

Is the rule on transactional boundaries around Aggregates just a nice-to-have, or should it be enforced religiously?

[Simon Jewell]

I would try to enforce updating only one aggregate at a time absolutely while you're learning. If you feel the need to update multiple aggregates in one go then it's more than likely that you're domain is lacking something and needs some deeper understanding. You may find as you get more experience that there are certain scenarios that you can break this rule but they would be very rare.

In general, using domain events gives the ability to chain together multiple things that need to happen but you won't be able to rollback anything that previously happened. If you need rollback then look into Sagas and/or process managers.

[Andrew Easter]

Hi Simon.

I'm in agreement with you on this. It would seem reasonably rare to be in a situation where taking retrospective compensatory action wouldn't be adequate. I'm far more comfortable with the idea of using domain events in the way you describe, and I can foresee a pretty slippery slope if you set out from the beginning relaxing rules around transactional boundaries.

If I've learnt anything from software engineering over the years it's that, despite the good intentions of developers, if it's easy to make compromises, compromises will inevitably be made with increasing frequency. In this case, if you build a system that makes it easy to draw a transaction boundary at the application service level, it's inevitable that developers will eventually make use of it in ways that you never planned for them to.

Thanks for your thoughts.

[Simon Jewell]

I couldn't agree more with that!

I think one of the more understated benefits of using DDD (+ Event Sourcing) is that everything has it's place; there are patterns to follow. I've worked on so many projects where it's just a free-for-all that just ends up in a big ball of mud.