第五章節：關於 CQRS - Kyle

[kylemocode]

在讀這章資料庫的讀寫分離的時候讓我想到之前偶然看過的 CQRS (Command Query Responsibility Segregation，命令查詢分離)架構，也有人同樣稱它為「讀寫分離」，自己有點沒有很懂 CQRS 的定義，以及 DB 的讀寫分離算不算是 CQRS 的實踐？或者是說兩者完全沒有關係？

目前自己觀察到的關於 CQRS 特性：

• Event Sourcing
• 處理複雜查詢

目前專案大致上的架構

這問題可能有點菜，但真的一直搞不清楚QQ

[jxiu0129]

\跪求再一篇「假詢問真分享文」/

[Parkerhiphop]

我最近才開始碰 CQRS，前幾天看到的文章來理解 CQRS 是一種分散式系統的實作概念，實作上感覺就是在做讀寫分離（但好像也不能這麼簡化）。 而在 DB 跟 Application 端都有各自的實踐方式，DB 的實踐之一就是本章講的 Replication，而 Application 的實踐就是用 Query & Command 來分別讀寫。

基本上就是從這篇搜尋 CQRS 很前面的文章看來的，再求大神分享 >< https://medium.brobridge.com/%E6%B7%BA%E8%AB%87-cqrs-%E5%AF%A6%E7%8F%BE%E6%96%B9%E6%B3%95-3b4fcb8d5c86

補充 NestJS 有內建 CQRS Module https://docs.nestjs.com/recipes/cqrs

[AK4codee]

呀真巧 我公司就是用 CQRS 其實我在準備面試時有試圖了解一下 CQRS ，也覺得不太理解 實際操作起來...就真的只是讀寫分離(如果我沒漏看甚麼的話)

基本上就是會分 Query & Command 兩個 SQL，API 如果是 GET 就是從 Query(Read-Only) 撈資料；如果是 POST 就是寫入 Command 那邊的資料庫。(我覺得我講的真爛XD) MySQL 可以設定主從資料庫同步(雖然我還沒開始研究怎麼做)，通常主是 Command，從是 Query，MySQL 會自動同步主庫的資料到從庫，這樣可以保持 Query 在 Read-only 的情況下更新寫入的資料。

另外，我們也有使用 MediatR 建立 Handler 處理 Command 事件，簡單做到 CQRS 架構上的分層。(但這邊感覺偏實作)

[Parkerhiphop]

你在讀時，就不要寫，反之亦然，一次做一件事。 Redux 其實也能算接近的概念。

Event Soucring

• 很多人會把他與 DDD 混淆。
• 但講白話點，就是一個 state 經過了單條線（一個 event）後成為另一個 state，類似 time machine 的概念，也可以 rollback
• 只要不要有繞一圈回來的情況就不會有什麼問題
• 所以銀行業很愛用

DDD

• 先定義出 Domain
• 有了 Domain 就很容易把東西放到 Event 操作
• 初衷是讓 工程架構 使用「Domain」 也能被 PM 和專案中的其他人所理解

CQRS 其實處理的是複雜的狀態變化、命令，不一定是查詢 像是當 Application 很大時，一個 Event 會有很複雜的命令操作。