Avoid Unit of Work pattern in domain driven design

Elisabeth picture Elisabeth · Feb 4, 2013 · Viewed 12.5k times · Source

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

Boris Tsema picture Boris Tsema · Feb 5, 2013

(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.