开发者社区> netfocus> 正文

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.


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Why系列:如无必要, don't 使用delete
啥,你要给我讲啥, delete? 哈哈哈哈哈哈哈哈哈 这里大家可能要笑了,这不就一个操作符吗,还用单独来讲。 有这时间,还不如去看看react源码,vue源码。 我说:react源码会去看的,但是这个也很挺有意思的。
79 0
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发起请求。
65 0
2015-03-18 current note update logic in my task
2015-03-18 current note update logic in my task
31 0
simulation pipeline after change not refresh issue
simulation pipeline after change not refresh issue
44 0
2015-03-17 current note creation logic in my task
2015-03-17 current note creation logic in my task
46 0
why My Lead OPA test add Lead fails
why My Lead OPA test add Lead fails
62 0
Support read and update operation on CUSTOMER_H extension fields
Created by Jerry Wang, last modified on Dec 24, 2015
64 0
my Lead add Lead test
Created by Wang, Jerry, last modified on Jul 06, 2016
50 0
+关注
netfocus
对DDD领域驱动设计感兴趣,在.NET/JAVA平台都有多年工作经验。架构方面专注于CQRS/Event Souring/EDA架构的研究和框架开发。热衷于开源,拥有两个个人开源项目:ENode,EQueue
文章
问答
视频
文章排行榜
最热
最新
相关电子书
更多
Towards A Fault-Tolerant Speaker Verification System: A Regularization Approach To Reduce The Condition Number
立即下载
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载