Avoid Unit of Work pattern in domain driven design

Question

I have read this and it makes me think twice...:

"Avoid unit of work pattern. Aggregate roots should define transaction boundaries."

Why should someone avoid the UOW pattern applying domain driven design?

Answer 1

(Before my post I recommend to read this chapter of "Implementing Domain-Driven Design" book by V. Vernon. It can help to get close with aggregates and contain long answer on your question.)

In a properly designed system one command changes one aggregate at a time, every aggregate has boundaries which defined by invariants in aggregate root. So when you do any changes on aggregate, invariants are checked and changes are applied (or not) in one transaction. It's transaction consistency. Do you need to use Unit of Work here? Don't think so.

But quite often we are in situation when more then one aggregate need to be changed at one time. Transactions become larger, they touch more then one part of a system and we talk about eventual consistency. UoW is a good helper in this case.

As it has been mentioned with no context it's hard to guess what author was thinking, but I suppose he told about transaction consistency case. In distributed system you will need to use something like UoW to provide eventual consistency to a system.

Answer 2

Basically, according to M. Fowler, the UoW is "just" a smart persistence tool (however complex this task may be). So IMHO there is no intrinsic incompatibility with the DDD approach, which gives guidelines more about the "spirit" of your doman modeling than about technical tools.

With no context, it's hard to tell what the author of the citation was thinking; but maybe he wrote this because when using UoW, it is often difficult to enable your entities to manage their own lifecycle (as well as others'), typically with persistence and transactional behaviour.

As a matter of fact, it is possible to use the UoW pattern in a DDD-style applications with AOP. With this kind of tools, it becomes possible to keep the DDD spirit, with entity-centric, business-capable domain model(s), while leveraging complex yet business-orthogonal mechanisms to achieve proper transactional persistence.

Typically, in the Java world, you may use in your DDD app:

• Hibernate/JPA as a UoW: provides "smart persistence" of your domain model entities (which may be JPA @Entity's as well)
• Spring AOP + AspectJ: provides DI in the entities
• Spring TX + AspectJ: enables transactional methods in your entities

These give DDD-ready (and heavily-@nnotated ;]) entities.

Answer 3

First up, an aggregate is an object for holding a set of loading entities, for a command to be applied to.

• Entities can belong to many different aggregates.
• Each command can only talk to one aggregate, which should have all the entities the command needs on it.
• Aggregates can be reused between commands.

A "Unit of Work" is basically an on-the-fly aggregate, allowing a single transactional update to a set of entities, without having to explicitly define in code an aggregate to do this.

This comes at the cost of not having an explicit Aggregate class on which to put mutation methods which protect your invariants.

The top voted answer contains:

But quite often we are in situation when more then one aggregate need to be changed at one time. Transactions become larger, they touch more then one part of a system and we talk about eventual consistency. UoW is a good helper in this case.

This is nonsensical, because, by definition, an aggregate is the set of stuff needed for a transaction. If you find that you "need entities from two different aggregates", then actually what you need is to "define am additional aggregate which holds references to the entities required".