以下内容翻译自 CQRS by Martin Fowler，有一些修改：
CQRS（Command Query Responsibility Segregation）指的是命令查询职责分离。这是一种我从 Greg Young 处听到的模式描述。它的核心思想很简单，就是你在更新和读取操作时使用不同的模型，这样的话，会给整个系统的设计带来深远的变革。
人们和信息系统交互的主流行为就是对数据仓库 CRUD 的使用，我们构思一个可以供创建、读取、更新和删除的数据模型。简单来说，我们的接口提供出来的目的就是供存储和获取数据之用的。
现在我们要脱离这样一种模型，看看另一种存储数据的方式，可能是把很多数据打包成一个数据对象，或者把一些数据按照某种格式压缩成一种新的格式存储起来。在数据更新这块，我们可以找到一些校验方式来对上述要存储的数据进行校验，甚至可以推断出我们提供的数据和现有的存储数据有什么不同。
传统方式：
这样一来，我们可以开始用多种视角来看待数据的呈现了。当用户和数据交互的时候，他们使用的是不同种的数据呈现方式。开发者通常会构建他们自己觉得正确的核心属性的概念模型，如果你在使用领域模型，那么这就是一种概念上的领域模型的表达，你当然也可以对数据的存储定义这样的一个概念模型。
今天提到的方式：
CQRS 则做了改变，它将这个模型拆分成命令和展示两部分，分别叫做 Command 和 Query。这样对于很多问题，特别是复杂的领域，相对于对命令和查询使用同一概念模型，复杂性降低。
把模型拆开来，这意味着可以用不同的逻辑进程、不同的硬件来做这两部分事情了。一个 WEB 上的例子，用户查看页面的时候使用查询模型；而如果要改变数据，这种改变会解析成若干命令模型来执行操作，操作完毕后通知状态的更新。
这里有一些变数需要考虑，内存中的两种模型可以来自同一个数据库，但也可以来自不同的数据库。比如可以让数据的查询来自实时的 ReportingDatabase（一种只提供读取服务的数据库概念，Bliki 上尽是概念，有的东西还真不怎么样，呵呵，译注），这样的话就需要一种存在于不同数据库之间的数据通信机制。
两种模型，那么原本相同的对象就需要不同的方法来操纵和查询了，就像关系数据库中的不同视图。不过我一听说了 CQRS 的介绍，这两种模型在脑海里一下子清晰起来。
我们把一个通过 CRUD 来交互的模型，挪到基于事件的 UI 层，对于基于事件溯源的场景我们使用命令模型。如何保持两种模型的一致性呢？这里需要考虑事件层面的一致性。很多情况下只有你在更新数据前才需要执行业务逻辑，所以使用 EagerReadDerivation（这个我不知道怎么翻译，建议大家打开链接看一看，读请求可以直接从 ReportingDatabase 中获取数据，而不经过逻辑处理，这个思路是有些奇特，见下面的图，译注）来简化你的查询模型是有很大意义的。
像很多模式一样，CQRS 只在某些场合适用，它带来了一种思维上的跳跃，如果不能从中获益，就不要考虑它。尤其值得一提的是，CQRS 只在某些特殊系统的某部分中使用（如面向领域设计中提到的 Bounded Context）。
目前为止我只看到只有两个方面在此获益。一个是针对非常复杂的场景，可以用 CQRS 简化问题。通常我尽量不这么做，因为在命令和查询两部分重叠较多，有足够多的方法属性可以重用；另一个情况是对于高性能的应用，如果读写比例太悬殊，
CQRS 可以让你分开考虑横向扩展，即便是传统方式，你也得对读写考虑不同的优化策略。一个例子是使用不同的数据库访问技术来处理查询和更新。
如果你的场景不适合使用 CQRS，但是你又面对查询的复杂性和性能问题，你仍然可以试试这个 ReportingDatabase，因为这样你仍然可以使用你原来的系统，只是对于一些特殊要求的查询，切换到这个 ReportingDatabase 上去（我通读了一下关于这个东西的文章，也没有见到它有特别优秀的地方，再者，对于这样一些变态场景，更可能会考虑的是一些成熟的读写库分离技术，译注）。
我们目前还没有看到很多使用 CQRS 的地方，我们理解大家对它赞成和反对的理由，CQRS 依然是我工具箱中必不可少的一把利器，虽然我不经常使用它。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
×Scan to share with WeChat
