Is multiple aggregates update in one transaction good?

简介:

I don't believe there is anything wrong with using multiple repositories to fetch data in a transaction. Often during a transaction an aggregate will need information from other aggregates in order to make a decision on whether to, or how to, change state. That's fine. It is, however, the modifying of state on multiple aggregates within one transaction that is deemed undesirable, and I think this what your referenced quote was trying to imply.

The reason this is undesirable is because of concurrency. As well as protecting the in-variants within it's boundary, each aggregate should be protected from concurrent transactions. e.g. two users making a change to an aggregate at the same time.

This protection is typically achieved by having a version/timestamp on the aggregates' DB table. When the aggregate is saved, a comparison is made of the version being saved and the version currently stored in the db (which may now be different from when the transaction started). If they don't match an exception is raised.

It basically boils down to this: In a collaborative system (many users making many transactions), the more aggregates that are modified in a single transaction will result in an increase of concurrency exceptions.

The exact same thing is true if your aggregate is too large & offers many state changing methods; multiple users can only modify the aggregate one at a time. By designing small aggregates that are modified in isolation in a transaction reduces concurrency collisions.

Vaughn Vernon has done an excellent job explaining this in his 3 part article.

However, this is just a guiding principle and there will be exceptions where more than one aggregate will need to be modified. The fact that you are considering whether the transaction/use case could be re-factored to only modify one aggregate is a good thing.


目录
相关文章
|
Web App开发 存储 前端开发
Why系列:如无必要, don't 使用delete
啥,你要给我讲啥, delete? 哈哈哈哈哈哈哈哈哈 这里大家可能要笑了,这不就一个操作符吗,还用单独来讲。 有这时间,还不如去看看react源码,vue源码。 我说:react源码会去看的,但是这个也很挺有意思的。
156 0
Why系列:如无必要, don't 使用delete
Multiple Origin composition test - Opportunity Creation case
Sent: Wednesday, 3 December, 2014 2:48 PM 结论是:如果gateway系统上针对一个odata service维护了多个mark成default的backend system,在creation的case下,runtime时候gateway只会向第一个 Default system发起请求。
109 0
Multiple Origin composition test - Opportunity Creation case
2015-03-18 current note update logic in my task
2015-03-18 current note update logic in my task
72 0
2015-03-18 current note update logic in my task
why My Lead OPA test add Lead fails
why My Lead OPA test add Lead fails
103 0
why My Lead OPA test add Lead fails
When should reread of cl_crm_bol_entity and $scope.$apply be called manually
When should reread of cl_crm_bol_entity and $scope.$apply be called manually
119 0
When should reread of cl_crm_bol_entity and $scope.$apply be called manually
2015-03-19 header note update in my Appointment
Created by Wang, Jerry, last modified on Mar 23, 2015
108 0
2015-03-19 header note update in my Appointment
my Lead add Lead test
Created by Wang, Jerry, last modified on Jul 06, 2016
my Lead add Lead test