一个对象属性方法在运行时再做Mixin，只是技术层面解决方案，

在领域层很也是难理解的，负影响也不小

[该贴被clonalman于2012-08-31 11:47修改过]

[该贴被clonalman于2012-08-31 11:57修改过]

嗯，那么我们看看scala，一般使用Scala的Actor模型来实现实体，Actor与外界交互都是消息，类似事件，这也是来自ERlang的并发模型，但是需要实体extends继承一下Actor(这与我们引入角色字段类似)。

所以，是否可以得出，领域和架构因为本来是正交的两件事，要将它们完美交合在一起，焊点总会看到? 呵呵。

Scala这个体系不是很了解(没时间研究)。:(

(实体直接继承Actor这个不好看吧，现在不都强调Pure Object)

领域与架构要找到一个结合点的话，

Bounded Context或Repository应该是再合适不过的了，用它来屏蔽技术细节

[该贴被clonalman于2012-08-31 12:32修改过]

再回到CQRS应用场景，CQRS和Event Source是密切相关的，ES属于CQRS中的Command部分，MartinFowler的ES文章谈到，将导致状态变化的所有事件提取出来。

比如我们原来没有在业务上引入考虑事件这个角度：

上面是典型的SSH或javaEE实现的方式，一个服务一个实体，而引入事件之后，如下图：

那么正如大部分系统都可以引入服务这个概念，“服务”这个概念既是业务也是技术概念，成为业务和技术架构的桥梁，谈到服务，业务人员知道它在业务上代表什么，技术人员知道如何实现它。

而“事件”也是一种和“服务”类似的介于技术和业务之间桥梁的术语，通过引入事件，应该不会对业务领域包括实体有伤害作用，也不会感觉它是天外来客或神仙姐姐，否则服务这个概念也应该是了。

不知上面观点是否认可？呵呵。

相关讨论：

业务建模: CQRS是鸡肋？

数据Data 上下文Context 交互Interaction(DCI):面向对象范式的演进

[该贴被banq于2012-08-31 16:07修改过]

领域上“需要记录船经过的港口”与技术上Event Sourcing,刚好重叠而已

如果领域需求根本不许要记录船经过的港口，ShippingEvent根本就没有必要，

也没有必要使用CQRS,Event Shourcing（个人观点）