贴张图 感觉挺有意思的 一张图胜 千言万语啊~~

[该贴被conquersky于2009-12-30 21:28修改过]

这篇文章 讲得很好 ~~~ 大家可以看看

通过阅读 我发现 上面链接的文章 有一个新概念，就是对于事件存储的概念，原文貌似把修改对象状态的事件 从领域对象中 隔离出来了。。。。而且跟领域对象本质的行为进行了分离，在这我感觉就有点模糊了。。。。 这两个的根本区分点在哪里呢？

将事件和状态分离这实际就是GOF状态模式的核心。这和我们进行用例分析时的强调状态用例也是一致的。

状态机核心就是：你告诉我事件，我返回给你状态，整个系统的核心就是由状态机控制，状态切换规则被封装在状体机中，输入输出只有触发状态切换的事件。如果能对GoF设计模式透彻了解，就对事件状体分离不是很疑惑。

在CQS中，由领域对象封装状态机，状态机是领域对象的核心，事件在整个分布式网络中不断被触发再分发，而封装状态机的领域模型则是分布式环境中一个个重要基地。这和宇宙大战模型很类似。
[该贴被banq于2009-12-31 10:42修改过]

Greg Young著名的PPT：
释放你的领域
主要几个思想：
1.Explicit State Representation强调状态表达，状态转换很重要必须被建模，
Event Storage
Command Query Separation
Asynchronous Context Mapping

CQRS,将事件分离出来，每一个Action都有与之相关的Event而且每个Event都要保存起来．不知道这样会不会带来一些性能问题，另一个问题是如何处理Event这种带Version的并发的问题呢？
[该贴被xinying_ge于2010-01-19 09:31修改过]

这些问题确实比较复杂，不必应用者参与，Tokyo Cabinet 和Tyrant 这样的key-value存储产品已经封装了这些Event的分发，如下图，update log实际就是更新事件的记录：

[该贴被banq于2010-01-19 10:44修改过]

Map-reduce讲究:已慢慢走向云计算了。。。。

有意思!

稍微实践了一下，还有很多不懂的东西。
一点点感觉，CQS一个大的优点是屏蔽掉了数据库驱动或页面原型驱动对业务对象的污染。

的确是实践出真知啊。

banq二楼的发言，实践后才能品出其中真味。

对象是一组行为及与之相关数据的集合，事务给了我们以单一（或者部分组合）行为观察对象的能力。这一能力在分布式传输中真的很牛叉。

大体看了下，CQRS必须要采用EVENT STORE这样的方式才能保证最终一致性。那具体应用上EVENT store的时机是在什么时候？在什么时候回放？

mark