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

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

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

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

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

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

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

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

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

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

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

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

同理，架构对领域的影响（从领域出发）可能是：

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

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

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