3種CQRS架構模式介紹

這篇文章主要講解了“3種CQRS架構模式介紹”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“3種CQRS架構模式介紹”吧！

CQRS 架構

CQRS 建議將應用程序層分為兩個方面，即命令端（Command）和查詢端（Query）。

查詢端負責優化讀取數據。從持久化獲取數據，然后將它們映射到展現層表單，這些表單通常被標識為數據傳輸對象（DTO）。

命令端關注優化寫入數據。命令執行各種用例，修改實體狀態并將其持久化。

通過分離讀寫操作，我們提高了性能，并在系統中支持關注點分離原則。

本文介紹 3 種主要的 CQRS 架構實現。

單數據庫 CQRS

單一數據庫CQRS 模式沒有正式名稱，Mattew Renze 在他的課程Clean Architecture 中將其命名為單一數據庫 CQRS，我也選擇這個命名。

顧名思義，雙方都在和一個數據庫對話。Command 在域中執行用例，從而修改實體的狀態，然后通過 ORM 如 Entity Framework Core 或 Hibernate 將實體保存到數據庫中。

Query 直接通過數據訪問層執行，數據訪問層要么是使用各種 ORM，要么通過存儲過程。

雙數據庫 CQRS

在“雙數據庫”方式中，我們需要兩個數據庫，一個用于寫操作，一個用于讀操作。命令端使用針對寫操作優化的數據庫。查詢端使用針對讀取操作優化的數據庫。

命令每改變一個狀態，修改后的數據就必須從寫數據庫推送到讀數據庫中，或者作為一個跨兩個數據庫的分布式事務，或者使用最終一致性模型。

這種架構給軟件的查詢端帶來了數量級的性能提升，這是有利的，因為一般系統在讀數據上花費的時間一般比寫數據要更多。

事件源 (Event source) CQRS

最后一種是最復雜的 CQRS 架構。與前面兩種方式相比，事件源存儲數據的思路完全不同。

在事件源方法中，我們并不只存儲實體的當前狀態，而且將實體發生的每一個狀態作為快照來存儲。實體并不是以標準化數據的形式保存，而是通過事件的時間戳來保存它們的變更。

事件源帶有以下好處：

• 事件存儲包括完整的審計跟蹤，可以在需要嚴格監管的場景中派上用場。

• 可以在任何時間點重建任何實體的任何狀態，這對于調試非常有用。

• 可以重放事件，查看系統中任何時候到底發生了什么。這個功能對于壓力測試和 bug 修復非常有用。

• 可以輕松地重建生產數據庫。

• 有多個為讀優化的數據存儲。

但在另一方面，這種方式實現很復雜，如果你不能從其中受益，那么用這個模式可能適得其反。

感謝各位的閱讀，以上就是“3種CQRS架構模式介紹”的內容了，經過本文的學習后，相信大家對3種CQRS架構模式介紹這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！