[TOC] # [什么是CQRS?](https://www.cnblogs.com/mouhong-lin/archive/2012/03/23/what-is-cqrs.html) UI 上有两种类型的操作：命令和查询，例如显示销量最好的5个产品就属于查询，而提交一个订单、修改密码等则属于命令。因为大部分系统都是读多写少，而且业务逻辑基本都出现在写入的一端，所以查询和命令的分离可以让我们独立的去优化查询。 # [用 CQRS/ES 模式构建弹性 Node.js 应用](https://medium.com/@domagojk/patterns-for-designing-flexible-architecture-in-node-js-cqrs-es-onion-7eb10bbefe17) 查询职责分离模式（Command Query Responsibility Segregation，**CQRS**），该模式从业务上分离修改 (Command，增，删，改，会对系统状态进行修改）和查询（Query，查，不会对系统状态进行修改）的行为。从而使得逻辑更加清晰，便于对不同部分进行针对性的优化。 事件溯源（Event Sourcing，**ES**）模式则是不保存对象的最新状态，而是保存对象产生的所有事件，所有由对象产生的事件会按照时间先后顺序有序地存放在数据库中。因为是用事件来表示对象的状态，而事件又只会增加不会修改，这就能让数据库里表示对象的数据非常稳定。这种特性可以让领域模型非常稳定，在数据库级别不会产生并发更新同一条数据的问题。 本文中作者结合 CQRS 和 ES 两种模式，尝试在工程应用中达到如下目的： 从实现细节中剥离出核心业务逻辑； 具体实现不依赖任何数据库、框架或者服务； 尽可能使用简单纯函数 让项目工程更容易水平扩展 让项目工程更容易测试 … 不过话说回来，一方面使用 CQRS/ES 确实能让应用程序变得更健壮、更好的扩展性，可另一方面也会给系统添加额外的复杂度，且架构实践门槛较高需要成熟框架去支撑；所以并非所有应用都要应用 CQRS/ES 模式，我们应该在必要的时候选择正确的方案。 # 参考 [深度长文：我对CQRS/EventSourcing架构的思考](http://www.uml.org.cn/zjjs/201609221.asp)