新项目的CQRS设计

　　刚换了个工作，闲话不说了。前两天开始一个新项目，大概是一个任务管理系统，由使用者来选取任务，执行任务，反馈完成，我大概做了些设计，本来是打算看能不能在新公司铺垫一下DDD，不过后来这块功能没分到我这，也就没办法了。不过如果分到我这，这个设计估计也不能写博客发了。

　　具体需求不多说，这个系统很像穿越小说里的佣兵悬赏系统。

　　发布任务，由被认证为有资格执行的人去抢任务，抢到了任务，去执行任务，完成任务获得金币奖励。

　　很清晰的几个阶段，状态迁移，阶段之间的交互比较单纯，线性的，同时又不需要什么返回值，这几点上考虑，我首先想到了命令模式。同时没提到的需求是，任务多是针对一类对象，这类对象在任务执行的流程中经过分析，其状态与任务状态虽然不同，但变化几乎是同步的，有很大一致性，很明显，非常适合作为一个聚合，任务作为聚合根。确定了命令模式和聚合，作为一个可能会有一定压力的系统来说，大体上选用CQRS基本上是第一反应了。

　　首先，用一个序列图验证一下思路是否行得通(ExpressParcel指的是任务针对的那类对象)：

　　　　　　　　　　　　　　　　

　　命令的大致流程都差不多，就不一一贴了，当然不一定是这么多create，大致看上去，是行的通的。

　　整理下，大概都用哪些对象，哪些命令：

　　　　　　　　　　　　　　　　　　　　　　　　

　　上面是聚合，接收命令的服务和命令的发出角色，下面是命令：

　　　　　　　　　　　　　　　　　　

　　命令的作用其实也很简单，只是通知状态变化和积分金币的变化。另外，还有一块，只画了个意思，就不贴了。大概说一下，CQRS的重点是读写分离，从这个角度来说，它对性能是比较关注的，命令模式也很适合异步执行，有助于吞吐能力的提升，而为了更进一步的提升，在TaskService接收了命令后，可以不直接执行，而将命令转为事件消息放入消息队列，由另外的服务去拉取执行。到这里，非常适合这种架构也是多数这种架构采取的配套方案也就是事件持久化了，补充一句，这里的事件只是一个概念，说明需要发生什么，并不是指.net的event之类的。不过我并没打算采用事件持久化的方案。

　　下面说一下我感觉的事件持久化的优缺点，也方便有合适的场景的时候斟酌使用。

　　优点：可以让静态的数据反映出系统曾经发生过的所用动态的变化，弥补了日志的不足，对监控有很大帮助；

　　　　　使数据库结构变得简单，主要部分的基础结构只有一种，就是事件的结构；

　　　　　让程序员可以更专注于逻辑和业务，脱离表驱动造成的数据库与逻辑的耦合，避免被静态数据限制动态的业务。

　　缺点：查询统计BI等需要另外一套表结构，也就是一份数据需要保存两种不同的形式；

　　　　　一旦系统需要重启，所有事件都需要重演，即使使用快照也不能彻底解决问题，启动时间长，不利于频繁的迭代发布；

　　　　　局部小附加功能的灵活性无法保证，除非系统不使用统一的解决方案。