DDD-CQRS的落地案例

摘要

在之前的文章DDD-CQRS能解什么问题中，阐述了什么是CQRS。但是并没有业务需求可以应用CQRS。最近需要处理一个文本增量更新的业务，经过需求分析后，尝试使用CQRS来解这个问题

问题分析

一个文本页面编辑，对象很大，之前是全量保存。涉及到的网络传输对象比较大，经常超时OOM，所以交互改成，只保存修改的部分，也就是增量更新。

之前业务中没法使用CQRS,在于使用CQRS后，数据的维护变得异常麻烦。比如我对一个表单进行了反复修改，生成了N份历史修改数据，获取最新数据时需要对这些历史数据进行合并，变得异常麻烦。
这次业务能够使用在于，

拆分写，能够有效的减少数据传输。
读写可以分离，分别扩展
通过事件溯源，可以恢复数据到任意编辑的版本

具体设计

系统整体采用CQRS+Event-Sourcing来实现

CQRS

CQRS模式通过使用不同的接口来分离读取数据和更新数据的操作。CQRS模式可以最大化性能，扩展性以及安全性，
还会为系统的持续演化提供更多的弹性，防止Update命令在域模型Level发生冲突。

文本编辑这块领域模型很薄，没有什么领域校验与约束，按读取数据/更新数据分离，当读写压力不同时，以后可以拆分成不同的服务，分别扩展。

Event Sourcing（事件溯源）

a.不保存对象的最新状态，而是保存对象产生的所有事件
b.通过事件溯源（Event Sourcing，ES）得到对象最新状态；

系统整体分为三大部分

一. command

所有数据修改命令，更新Command、撤销Command、覆盖Command
会持久化存储到CommitRepository中。然后发出事件消息

二. event-handle

对于文本编辑这个case，事件处理主要是合并提交的command event。否则事件溯源时，需要处理的数据更新事件太多，耗时太长。

三. query

查询数据,能够根据修改记录获取任意commit的数据。

三大部分分离，可以部署为单个服务，也可以解耦为多个服务，便于扩展。

需要解决的问题

如何保证事件的有序性

CQRS的一个典型问题就是生产端的事件顺序和消费端的事件顺序不一致，导致数据不一致的问题。如何去解决呢？

Command处理部分处理所有的数据更新部分，会生成一个全局有序的commitid，代表着更新的顺序。也就是生产端的事件顺序，但是到达我们消费端的顺序却不一定是这个顺序。所以消费端，事件处理完成后，会更新消费的最新commitid。如果当前事件的commitid小于最新的commitid，事件遗弃。