[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)
- PWA 概念
- Immutable
- Angular 基礎概念
- 入門參考
- Angular 更新總結
- Angular 生態系統
- Rx.js
- Ngrx
- CQRS/ES 模式
- Angular 5 詳解
- 測試
- 定義共享模塊
- 懶路由加載
- angular組件
- 雙向綁定及變化檢測
- 樣式
- ionic 3詳解
- ionic3
- ionic 插件
- Ionic 添加動畫
- Ghost-Loading
- 打包發布
- Android上架國內應用市場流程
- 總結
- 文章
- 問題合集
- Cordova
- 插件開發指南
- Android插件開發指南-官網
- IOS插件開發指南-官網
- Hooks 編寫
- 橋接技術
- ===cordova插件收集===
- 相關主題-官網
- 實戰-自定義插件流程
- UI 及 相關資源