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.