Gojko Adzic » Evolution of DDD: CQRS and Event Sourcing
Greg Young 一直在DDD实践领域很活跃，CQRS倡导将读写分离，那么读写分离以后，我们是否需要使用同一个数据源呢？
Greg Young倡导将查询读的数据和命令修改的模型都是同一种正常的领域模型，我们所做的就是在两者之间同步，比如ForumMessage这个正常的领域实体模型，既可用在命令事务中，也可用在查询中，关键问题是：模型在命令中如果被修改，如何及时更新同步查询。
该文提出，模型在命令事务结束后，可以发出Event事件 domain events更新查询。当然，进一步，可以实现Event 存储，这样有利于测试跟踪调试，也有利于使系统更加健壮，如果哪个环节出错，我们replay一下事件即可。
简单事情复杂化，封装若干层以后除了增加复杂度和加大维护的门槛没有任何好处，觉得绕了N多圈依然回到原处。
真正的OO要从自然界中习得，学习上帝的设计方式。
事情远没你想得复杂，又比你想得复杂。
用消息代替数据是一种良好的系统解耦合的方式，也是符合自然世界中现实情况的方案。
本质上是接口定义方式的转变，从“你要做什么”转变为“发生了什么事”。模块基于对纯粹业务过程的理解才能够变得通用。
试问，为什么要在domain对象中操作数据库或者一些基础设施？
发消息和我直接调用又有何不同
你不一样和消息耦合了吗
自欺欺人而已
无论发什么都离不开函数调用。这里提出的区别是在接口中传递的信息。
如果有人打开了电灯开关我们可以用2种方式对执行机构进行调用： 1. xxx.执行（开灯） 2. xxx.onEvent（灯开关被触动）
他们有什么区别呢？ 在1中调用者需要知道xxx是什么，他有什么样的功能以及在什么样的输入条件下会产生怎样的预期结果。此时调用者必须很熟悉xxx才能够使用。如果xxx被放置到另外的系统中，那么新的系统也必须学习xxx的所有相关细节。这种耦合是很复杂的。
在2中调用者只需要关心谁希望接受什么样消息，并不需要关心xxx对事件的反应，同时不需要预期xxx的执行结果，xxx完全是一个陌生人。当xxx被集成到新的系统中，新的系统也并不需要进行任何学习。这样所有的耦合仅仅集中到了消息本身。
消息是针对业务过程的，在一个特定的业务过程中消息的类型和内容也是稳定的，通常不会发生改变。这样所有的组件只需要按照这个统一的标准实现就可以了，在集成的时候不需要相互学习，这样的代价相对于直接调用是很小的。
同时基于消息的系统可以很方便的实现异步、回放、回滚=======操作，在一个大规模的系统中这些特性都是有着致命吸引力的。
》》》必须学习xxx的所有相关细节
你写消息对象和消息处理程序对象的时候也是要熟悉xxx的所有相关细节吧，否则怎么发出消息呢。
>>>在2中调用者只需要关心谁希望接受什么样消息，并不需要关心xxx对事件的反应，同时不需要预期xxx的执行结果，
你用发邮件说事还差不多，在绝大多数情况下，调用者很关心调用结果，如根据调用结果判断执行何种操作，你所说的消息机制，仅仅只能用于很少的场景。
他解决不了设计和架构问题 [该贴被tianhaoleng于2010-06-13 16:49修改过]
对于这篇文章的解读，我有些与banq不同的见解。
cqs本质上是个认知论的问题，c是以业务行为的视角观察事物，q则是以展示的视角观察。
具体到实际开发中，c属于domain的范围，q则是属于presentation的范围。从系统分层看，这是两个相互独立的层，但我们通常会用一个折中的观察视角得到的“业务对象”来贯穿p和d的操作，这种折中方式事实上既不利于p的使用，也不利于d的处理。 cqs就是要做到p的归p，d的归d。我个人的理解，domain object 和presentation使用的dto，应该以不发生关系为好。这样提供了p和d分别优化的能力，不过这也要求在部署上，p和d分别部署，让两套模型分别承载压力，否则系统性能是个问题，尤其是内存。
我是新手，见解较浅，错漏之处，还请诸位多多指点。 [该贴被FredWang于2010-06-13 22:18修改过]
evolution->演化, revolution->革命
非常精辟，但是在具体实现时，经常有一种误解，把关系数据库直接暴露给查询，这样容易造成查询输出和数据库技术耦合的问题，如果我们更换使用Hive这样NoSQL数据库作为查询数据挖掘报表输出的话，那么查询的应用程序会发生修改。
所以，我个人观点是：C和Q是分离了，但是他们应该基于同样的模型，否则，领域模型驱动一词成为空谈，只有我们应用的各种功能不依赖具体数据库技术了，这样的设计才是比较好的。
说实话，这个问题纠结我很久了。
企业应用中C和Q的模型统一真的满难的。
纯粹是放屁拉屎