业务建模:CQRS应用场景

12-08-29 clonalman
                   

THIS MESSAGE HAS BEEN MASKED

                   

10
banq
2012-08-29 18:29

看得出楼主是位实战经验丰富的大牛。读你的帖子是一种享受。

楼主已经看到了系统模块之间边界重要性,不同领域边界认为可以采取CQRS。通过事件或消息将模块之间进行切分松耦合又不失联系。

在经典解决方案中,还有引入SOA的JMS和ESB服务总线等方式来实现,应该和CQRS两者区别不大,两者都是异步方式,不同的是一个侧重事件,一个侧重消息。

当然,我个人认为CQRS和SOA还有一个本质区别,就是事件或消息的发源地不同,在CQRS中,由领域模型发出领域事件;而在SOA中,是由一个服务发出消息,这两种流派的竞争,就看你的应用是以服务为主,还是状态为主,当然,两者也是可以结合在一起的。

clonalman
2012-08-30 10:11

"大牛"不敢当,实践多了,总会有一些体会的 :)

任何“架构”对“领域模型”多少都有影响,

如果是这个影响正是领域“想要的”(正影响),就可以采用,否则(负影响)宁可不用;

采用哪个方案,都能到达目的地,就看你是像坐“火车”、“高铁”还是“飞机”

[该贴被clonalman于2012-08-30 14:30修改过]

banq
2012-08-30 16:42

2012-08-30 10:11 "@clonalman"的内容
如果是这个影响正是领域“想要的”(正影响),就可以采用,否则(负影响)宁可不用; ...

是啊,架构对领域的影响根据你的经验如何判断?特别是系统开始复杂时,“火车”“飞机”等方式可能影响的是不是效果不同?

clonalman
2012-08-30 19:47

同意,做飞机效果是好,但必须承受的负影响是:机票贵、 机场远、提前两个小时到达、飞机上不让打手机等。

如果说“我要到达某个地方,这个地方可能是很远”是领域模型,“飞机”是使用的架构,上面的负影响我根本不在乎,当然是使用“飞机”了;如果负影响是可能会发生“劫机”,那还坐不坐了?

同理,架构对领域的影响(从领域出发)可能是:

在领域层添加DCI里的Context、CQRS里的DomainEvent,如果这些元素是我们领域建模想要的、所期待的,就是正影响,反之,就是负影响。

所以,架构理解应该是领域某个特征自然延伸或实现方式,而不是用一个架构试图解决所有领域问题

[该贴被clonalman于2012-08-30 20:06修改过]

9Go 1 2 3 4 ... 9 下一页