CQRS

命令與查詢責任分離
(CQRS, Command Query Responsibility Segregation)

* Command:

會對資料引發side effect的操作(數據的變化ex:crud)

* Query: 查詢

有人會說他叫讀寫分離(狹義)

廣義CQRS

Repetition is greater than reuse

single source of truth呢？

CQRS v.s. CRUD

如果是比較簡單的商業邏輯,
還是會建議使用CRUD

如果需要各個方面的數據拼接,
那麼CQRS就是一個很好的解決問題

請先思考一下,DDD模式,某如果查詢知識領域沒有緊密的關係的話？

優點

可以在query端使用更貼近數據儲存引擎ex:nosql ,elasticsearch,

缺點

即時完整性問題

如果你的業務對於即時完整性很注重,CQRS不適合
如果你的業務只需要注重最終完整性,那CQRS適合

Demo v0.3+v1.3

CQRS講完了！

謝謝大家

Event Sourcing

 1. 整個系統都以事件驅動

 2. 商業數據只是一些事件產生的view,不一定要保存到資料庫中

* 優點: 就是可以簡單的"溯原"

* 缺點: 如果需要查訊最新狀態的話,需要大量運算,如帳戶餘額

Event Sourcing+CQRS名詞介紹

* Event：Event的影響(通常是一個命令的結果)

* Query：關心的是接收領域事件後,更新對應的數據

* Command：只需要關心領域模型是否更新成功,同時對領域對象保證數據的完整性

demo: v2.3 crud

Saga

Event可能失敗!!!

command觸發的事件在query是可能失敗的,
一旦失敗數據就會長時間處於不一致的狀態,需要外部介入

Saga

只要我們有多個存儲數據的地方(而不是在一個資料庫中)，
一致性就不會自動解決

多個微服務中處理一致性問題的最著名方法是SAGA模式
試圖以通用方案涵蓋所有的場景,業務補償就是saga的精神

Saga實做

demo: v2.3 後半段

* Event: 把所有event記錄下來,並且啟發saga

* Query: 關心的是接收領域事件後,更新對應的數據

* Command: 只需要關心領域模型是否更新成功,同時對領域對象保證數據的完整性
 

* Saga: 做出接下來的command與反饋機制

隱藏的祕密Saga