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?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
(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.