[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)