DDD CQRS和Event Sourcing的案例：足球比赛

那么我们从哪里开始改变？如何改变？

并不是从数据开始。而是从头开始，统一语言。

我们重新开始看看领域专家是如何描述需求的：

1.举办一个比赛，有两个队参加

2.比赛在某个时间开始，只能开始一次。

3.比赛结束后，统计积分

从这个需求中，我们会发现有一个聚合词语Aggregate: Match比赛。

这个比赛模型可以涵括需求的大部分。

那么“Match比赛”模型无疑是一个实体，是聚合根。它的重要特点是内部有状态，而且不能向外直接暴露这种状态；通过聚合根实体和外界进行交互。

通过实体“Match比赛”模型，可以创建值对象：两个队伍的名称，对象Team值对象，值对象是不可变的。

我们可以根据一个比赛名称开始一个比赛。我们也可以结束一个比赛，这时有值对象分数Score，也具有不可变性。

这样聚合根“Match比赛”有下列特点：

1.有自己的生命周期

2.有自己的事务边界。

3.克服了危险的setter方法

4.聚合体内：分数Score 队伍team和日期等模型是值对象不可变。

因为不可变，我们只留getter方法给它们，用户通过getter方法获得他们想要的数据视图。

这样， Match比赛 聚合根实体的代码如下，相当于将原来MatchService的代码移到实体类的方法中，再也没有了服务：

这样的代码代表富模型，充血模型，有如下好处：

1.有动词的模型

2.数据和操作数据的行为捆绑。

3.可以反应统一语言。

下面一步，我们再想想，如果也去除了getter方法如何？那么如何产生出给用户看的视图数据呢？

这时，我们也许注意到，我们是在从用户角度来看这个模型，而之前我们是从领域专家角度看模型，不同角度对模型的要求不同。

那么，我们索性从读写两个方面去看待模型，这就是CQRS：

写模型： 统一语言，显式的事务边界，复杂的业务逻辑。

读模型：专门为读优化(缓存等)，有不同的SQL如NoSQL分析，简单的类组成。

[该贴被banq于2012-12-14 14:15修改过]

使用事件Event。事件的特点：

1.可以描述状态变化，事件驱动状态改变。

2.准确描述已经发生什么，而不是将要发生什么或也许发生什么。

3.相对小。

4.无业务逻辑

5.可以由业务方法产生。

6.可以发送到队列Queue,异步。

那么，我们在实体模型Match中的方法中增加事件代码如下：

[该贴被banq于2012-12-14 15:10修改过]

由于序列化的事件可以保存在关系数据库 NoSQL 或文件中。我们必须采取分布式事务吗？相当复杂，不如只采取一种数据库形式，哪一种呢？虽然关系数据库很可怕，但是在mapping join query上比较稳定。可以采取关系数据库存储事件，用来保证事件的前后连续性。

当这些过去的事件被回放时，聚合体能够重新激活他们自己。

这样聚合根实体代码要做些改变，增加方法回放事件，将状态封装在回放方法中，这时就必须移除原来ORM元注解了。

Match类的代码改变如下：