當前位置：首頁 > 科技 > 軟件

DDD 與 CQRS 才是黃金組合

來源：責編：時間：2023-08-20 23:17:18 12828觀看

導讀在日常工作中，你是否也遇到過下面幾種情況：使用一個已有接口進行業務開發，上線后出現嚴重的性能問題，被老板當眾質疑：“你為什么不使用緩存接口，這個接口全部走數據庫，這怎么能抗??！”開發一個后臺管理功能，業務反饋說數據一直

在日常工作中，你是否也遇到過下面幾種情況：

使用一個已有接口進行業務開發，上線后出現嚴重的性能問題，被老板當眾質疑：“你為什么不使用緩存接口，這個接口全部走數據庫，這怎么能抗??！”
開發一個后臺管理功能，業務反饋說數據一直不對，對比后發現緩存與數據庫不一致，為什么要使用緩存接口呢，你陷入沉思？
產品要求在 xxx 上增加新功能，編碼、測試、上線一氣呵成，最后發現另外一個流程被躺槍，出現異常不得不進行回滾！
在一個高并發的場景，DB 成為了系統瓶頸，不加索引查詢扛不住，加索引更新扛不住，又該如何處理？
隨著數據量的激增，系統變得越來越慢，特別是后臺管理復雜的查詢場景下，復雜的 Join 讓 DB 不堪重負
……

為什么會出現這種現象？其本質仍舊是代碼組織結構不合理，我們將不同的復雜性揉在一起，從而造成了更大的復雜性，然后如此往復，不知不覺中陷入巨大的復雜性旋渦不可自拔。

1. CQRS 是什么？

CQRS 是 Command Query Responsibility Segregation 得簡稱，簡單理解就是對 “寫”（Command）和 “讀” （Query）操作進行分離。反應快的同學會說：“也不是什么高深技術嗎，不就是數據庫的讀寫分離嗎？”

是的，數據庫的讀寫分離也算是一種 CQRS，但 CQRS 的含義要比這復雜的多。

CRQS 既是一種流行的業務架構，又是一種設計思維。

CQRS 的核心是“拆分”，將復雜系統拆分為 Command 和 Query 兩個部分，針對不同的場景使用不同的模式，選擇最合適的技術落地最佳解決方案，避免兩者相互掣肘相互影響。

CQRS的目的是降低整個系統的復雜性，那它背后的邏輯是什么？

假設，在一個系統中：

Command 的復雜性為 M
Query 的復雜性為 N

如果使用同一套模型來處理 Command 和 Query，那在極端情況下，系統的復雜性為 M * N，因為兩者相互影響，調整一方的同時要時刻關注對另一方的影響。

圖片

這種“你中有我，我中有你”的設計方式，“兩者的相互影響”成為系統最為復雜之處，大量精力消耗在“排查影響”，而非最有價值的設計和編碼。

如果，將 Command 和 Query 徹底分離，系統的復雜性變成 M + N。Command 的變更不會影響 Query，而 Query 的修改也不會影響 Command。

圖片

當然，以上兩個極端在實際工作中也很少見，通常系統的復雜性介于兩者之間。

圖片

這只是從理論進行推導，在實際工作中隨處可見的“沖突”也是對“拆分”的一種暗示。

2. 分層架構中的沖突

以最常見的分層架構進行介紹，具體如下：

圖片

如圖所示，將系統分成5層，每層的含義如下：

Web 接入層。主要用于處理系統輸入，對輸入信息進行驗證，調用應用服務完成業務操作，對結果進行轉換，最終返回給調用方；
應用服務層。主要處理業務流程編排，從倉庫中獲取領域對象，執行領域模型的業務操作，將最新的對象狀態通過倉庫同步到數據存儲引擎，并對外發布領域事件；
領域層。業務邏輯的承載點，是業務價值的集中體現，通常構建于面向對象設計之上，基于封裝、繼承、多態等特性保障業務邏輯的復用性和擴展性；
倉庫層。主要用于數據訪問，向上為應用服務提供數據操作服務，向下屏蔽各類存儲引擎的差異；
數據層。主要用于數據保存和檢索，常見的數據存儲引擎全部屬于這一層，比如 MySQL、Redis、ES 等；

其實，分層架構本身也是一種“拆分”，將不同的關注點封裝在不同的層次。但除了橫向分層，還可以基于 CQRS 對其進行縱向拆分，也就是將每個層的組件拆分為 Command 和 Query 兩部分。

由于接入層沖突較小，本身拆分的意義不大，在此不做要求，但從嚴格意義上講，仍舊建議進行拆分。

3. 應用服務層沖突與拆分

應用服務層拆分就是將一個應用服務拆分為 CommandService 和 QueryService 兩組。

圖片

這樣做可以避免很多不必要的麻煩，Command 和 Query 存在較大的區別，具體如下：

	CommandService	QueryService
依賴組件不同	ValidateService 驗證服務；LazyLoaderFactory 延遲加載服務；CommandRepository 不帶緩存的倉庫；EventPublisher 事件發表器	QueryRepository 帶緩存功能的倉庫；JoinService 數據聚合服務；Converter 數據轉換服務
核心流程不同	驗證、加載、業務操作、同步、發布事件	驗證、加載、數據組裝、轉換
功能加強不同	主要是事務管理器	主要是緩存組件

回想開篇時提到的場景，完成應用層拆分，就不在為使用錯組件而煩惱：

CommandService 的 Repository 不使用緩存，僅操作數據庫
QueryService 的 Repository 可以使用緩存，以提升訪問性能

除此之外，針對統一的操作流程，還可以進一步抽象來消除重復的“模板代碼”，比如：

引入“模板方法設計模式” 以達到核心邏輯的復用

抽象出 BaseCommandService 和 BaseQueryService 兩個父類用于統一核心流程

子類實現 BaseCommandService 和 BaseQueryService 的抽象方法完成功能擴展

基于“約定優于配置” 使用 Proxy 模型，只定義接口不寫實現代碼
按規范定義 CommandService 和 QueryService 接口，通過注解完成相關配置
自動生成 Proxy 實現類，完成流程編排

4. 模型層沖突與拆分

模型層是系統的核心，它的設計直接影響整個系統的質量。作為承接業務邏輯的核心，比較流程的實現策略包括：

DDD 領域驅動設計，其核心是使用面向對象的高級特性（封裝、繼承、多態、組合等）來進行設計，非常適合復雜的業務場景。其體現就是存在很多高內聚低耦合的對象組（聚合根），業務邏輯由這些小對象相互協作共同完成；
事務腳本，使用過程式思維，將數據操作編織到流程中，比較適合并不復雜的業務場景。其體現就是存在很多“上帝 Service”，Service 中存在很多非常長的方法，業務邏輯由這些方法完成；

關于哪個才是最優解，網上已經爭論多年，最終也沒有結論。但我始終認為“沒有業務場景就討論方案，就是在耍流氓”。

從不同應用場景出發便可得到如下結論：

Command 場景需要保障嚴謹的業務邏輯，通常復雜性偏高，所以DDD 是最優解
Query 場景需要更靈活的數據組裝能力作為支持，通常比較簡單，所以事務腳本是最優解

我經常說：“最簡單的“寫”也是復雜，最復雜的“讀”也是簡單”，其背后邏輯是基于對 Command 和 Query 的場景判斷。

將模型拆分為 Command 和 Query，具體如下：

圖片

完成模型拆分后，新模型具有以下特征：

Agg 也就是 DDD 中聚合根，主要用于處理復雜的 Command 邏輯，由具有大量業務操作的"富對象"構成；
View 是標準的 POJO，主要充當 Query 結果對象，典型的“貧血對象”，僅作為數據的載體，根據展示需求對數據進行組裝；
View 沒有自己的 Repository，只能依賴 CommandRepository 獲取數據，Converter 組件負責將 Agg 模型轉換為 View 模型。

這塊是拆分的重點，為了方便理解，簡單舉個例子：

比如在電商的訂單模塊：

生單流程，由 Order 作為聚合根對內部 OrderItem 和 PayInfo 進行統一協調
訂單列表頁，只需展示 Order 和 User 信息
訂單詳情，需要展示Order、User、Address、OrderItem、PayInfo、Product等信息

如果讓一個模型同時支持著三個場景，那模型自己就變的非常復雜，很難判斷某個方法、某個字段究竟屬于哪個場景。

此時，應該根據場景對模型進行拆分：

OrderBO 以 DDD 方式進行建模，對外提供統一的業務操作，對內協調 OrderItem 和 PayInfo 等多個實體對象；
OrderListVO 以 POJO 方式進行建模，屬性中包含 Order 和 User 信息；
OrderDetailVO 以 POJO 方式進行建模，屬性中包括 Order、User、Address、OrderItem、PayInfo、Product 等信息；

三個模型相互獨立，互不影響。

當然，由于使用統一的 Repository 還需提供對應 VO 的 Converter：

OrderListVOConverter 將 OrderBO 轉換為 OrderListVO 對象
OrderDetailVOConverter 將 OrderBO 轉化為 OrderDetailVO 對象

5. 倉庫層沖突與拆分

倉庫層拆分也是非常有必要的，在這一層主要有幾項沖突：

	CommandRepository	QueryRepository
底層實現不同	主要基于 DB 實現	基于 DB、Redis、ES 等多種存儲引擎
方法復雜性不同	提供僅有的少量方法并足以支持大多數場景，比如 save、update、getById 等	根據業務場景進行定制，方法多種多樣（單條、批量、分頁、排序、統計等），維度多種多樣（id、user、status）
返回值不同	直接返回裝配完整的富對象	根據業務場景定制返回值

倉庫拆分后整體架構如下：

圖片

倉庫拆分具有以下特點：

View 不在需要 Converter 組件完成數據轉換
View 的數據來自于自己的 Repository，可以根據展示需求進行靈活定制
Command 和 Query 仍舊使用同一套數據庫、同一套數據表

6. 數據層沖突與拆分

數據層拆分是最重要的拆分，提到分離第一反應也是“數據庫主從分離”。

數據層拆分的本質是：各種數據存儲引擎的最佳應用場景相差巨大，讀和寫優化往往存在矛盾。

仍舊以最常見的數據庫為例：

提升查詢性能，建議為各種查詢維度建立索引
提升寫入性能，需要讓表上的索引越來越少
為了加速更新性能，建議使用三范式設計表結構，減少冗余信息
為了加速查詢性能，建議使用反范式設計，盡量冗余數據，避免數據表間的 Join 操作

魚和熊掌不可兼得，在數據庫層展示的淋漓盡致！

數據層拆分后架構如下：

圖片

該模型具有以下特點：

數據存儲進行了徹底拆分；Command 和 Query 都可以靈活的選擇最合適的存儲引擎；
Command 與 Query 需要引入一套同步機制以完成兩者的數據同步，常見的同步機制有：

工作在應用層基于領域事件的數據同步，如圖所示
工作在數據層基于log的數據同步，如 MySQL 的主從同步、Canal2XX 等

數據層拆分是大型系統最終的歸宿，仍舊以訂單系統為例：

訂單作為一致性要求極高的系統，Command 側首選仍舊為具有 ACID 的關系型數據庫，哪怕是分庫分表底層存儲仍舊不變；
為了滿足高性能查詢需求，需要在 Query 側引入 Redis 作為分布式緩存對訪問進行加速；
為了滿足后臺復雜且多維度的業務查詢，需要在 Query 側引入 ES 為全文檢索進行加速；
為了滿足各種實時報表需求，需要在 Query 側引入 TiDB 以滿足海量數據的實時檢索；

這就是我們面臨的現狀：“數據密集型系統”越來越多的應用程序有著各種嚴格而廣泛的要求，單個工具不足以滿足所有的數據處理和存儲需求。取而代之的是，總體工作被拆分成一系列能被單個工具高效完成的任務，并通過應用代碼將它們縫合起來，通過 API 的方式，對外提供服務，屏蔽內部的復雜性。

7. 小結

“拆分”是“分離關注點”的重要手段之一。拆分的目的是將問題進行歸類，然后采取有針對性的手段更好的解決問題。

CQRS 作為一種架構，將業務系統不同部分進行歸類，接下來需要為 Command 和 Query 尋找最優解決方案：

Command，以 DDD 作為理論基礎將戰術模型中最佳實戰進行落地，包括

聚合設計

倉庫設計

LazyLoad + Context 模式

業務驗證

領域事件

…

Query，以數據檢索和組裝作為核心能力，設計留給開發人員，實現留給框架，包括：

QueryObject 查詢對象模式
內存 Join 模式
寬表&冗余表模式

本文鏈接：http://m.www897cc.com/showinfo-26-6217-0.htmlDDD 與 CQRS 才是黃金組合

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： H5-Dooring可視化頁面制作神器測評總結

下一篇：資損防控技術體系簡介及實踐

標簽：

熱門焦點

俄羅斯：將審查iPhone等外國公司設備保數據安全

iPhone和特斯拉都屬于在各自領域領頭羊的品牌，推出的產品也也都是數一數二的，但對于一些國家而言，它們的產品可靠性和安全性還是在限制范圍內。近日，俄羅斯聯邦通信、信息技術
紅魔電競平板評測：大屏幕硬實力

前言：三年的疫情因為要上網課的原因激活了平板市場，如今網課的時代已經過去，大家的生活都恢復到了正軌，這也就意味著，真正考驗平板電腦生存的環境來了。也就是面對著這種殘酷的
6月安卓手機好評榜：魅族20 Pro蟬聯冠軍

性能榜和性價比榜之后，我們來看最后的安卓手機好評榜，數據來源安兔兔評測，收集時間2023年6月1日至6月30日，僅限國內市場。第一名：魅族20 Pro好評率：95%5月份的時候魅族20 Pro就是
5月iOS設備好評榜：iPhone 14僅排第43？

來到新的一月，安兔兔的各個榜單又重新匯總了數據，像安卓陣營的榜單都有著比較大的變動，不過iOS由于設備的更新換代并沒有那么快，所以相對來說變化并不大，特別是iOS好評榜，老款設
印度登月最關鍵一步！月船三號今晚進入環月軌道

8月5日消息，據印度官方消息，月船三號將于北京時間今晚21時30分左右開始近月制動進入環月軌道。這是該探測器能夠成功的最關鍵步驟之一，如果成功將開始圍
Temu起訴SHEIN，跨境電商戰事升級

來源 | 伯虎財經（bohuFN）作者 | 陳平安日前據外媒報道，拼多多旗下跨境電商平臺Temu正對競爭對手SHEIN提起新訴訟，訴狀稱Shein“利用市場支配力量強迫服裝廠商與之簽訂獨家
“又被陳思誠騙了”

作者｜張思齊出品｜眾面（ID：ZhongMian_ZM）如今的國產懸疑電影，成了陳思誠的天下。最近大爆電影《消失的她》票房突破30億斷層奪魁暑期檔，陳思誠再度風頭無兩。你可以說陳思誠的
簽約井川里予、何丹彤，單視頻點贊近千萬，MCN黑馬永恒文?？焖籴绕?！

來源：視聽觀察永恒文希傳媒作為一家MCN公司，說起它的名字來，可能大家會覺得有點兒陌生，但是說出來下面一串的名字之后，或許大家就會感到震驚，原來這么多網紅，都簽約這家公司了。根
2納米決戰2025

集微網報道從三強爭霸到四雄逐鹿，2nm的廝殺聲已然隱約傳來。無論是老牌勁旅臺積電、三星，還是誓言重回先進制程領先地位的英特爾，甚至初成立不久的新

日韩成人免费在线_国产成人一二_精品国产免费人成电影在线观..._日本一区二区三区久久久久久久久不

DDD 與 CQRS 才是黃金組合

1. CQRS 是什么？

2. 分層架構中的沖突

3. 應用服務層沖突與拆分

4. 模型層沖突與拆分

5. 倉庫層沖突與拆分

6. 數據層沖突與拆分

7. 小結

俄羅斯：將審查iPhone等外國公司設備保數據安全

紅魔電競平板評測：大屏幕硬實力

6月安卓手機好評榜：魅族20 Pro蟬聯冠軍

5月iOS設備好評榜：iPhone 14僅排第43？

印度登月最關鍵一步！月船三號今晚進入環月軌道

Temu起訴SHEIN，跨境電商戰事升級

“又被陳思誠騙了”

簽約井川里予、何丹彤，單視頻點贊近千萬，MCN黑馬永恒文?？焖籴绕?！

2納米決戰2025

最新推薦

猜你喜歡

熱門推薦

相關資訊

DDD 與 CQRS 才是黃金組合

1. CQRS 是什么？

2. 分層架構中的沖突

3. 應用服務層沖突與拆分

4. 模型層沖突與拆分

5. 倉庫層沖突與拆分

6. 數據層沖突與拆分

7. 小結

最新推薦

猜你喜歡

熱門推薦

相關資訊

1. CQRS 是什么？