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

DDD 與 CQRS 才是黃金組合

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

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

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

使用一個已有接口進行業務開發，上線后出現嚴重的性能問題，被老板當眾質疑：“你為什么不使用緩存接口，這個接口全部走數據庫，這怎么能抗住！”
開發一個后臺管理功能，業務反饋說數據一直不對，對比后發現緩存與數據庫不一致，為什么要使用緩存接口呢，你陷入沉思？
產品要求在 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://www.rrqrq.com/showinfo-26-6217-0.htmlDDD 與 CQRS 才是黃金組合

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

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

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

標簽：

熱門焦點

K60 Pro官方停產第三方瞬間漲價

雖然沒有官方宣布，但Redmi的一些高管也已經透露了，Redmi K60 Pro已經停產且不會補貨，這一切都是為了即將到來的K60 Ultra鋪路，屬于廠家的正常操作。但有意思的是該機在停產之后
0糖0卡0脂旭日森林仙草烏龍茶優惠：15瓶到手29元

旭日森林無糖仙草烏龍茶510ml*15瓶平時要賣為79.9元，今日下單領取50元優惠券，到手價為29.9元。產品規格：0糖0卡0脂，添加草本仙草汁，清涼爽口，富含茶多酚，保留
K8S | Service服務發現

一、背景在微服務架構中，這里以開發環境「Dev」為基礎來描述，在K8S集群中通常會開放：路由網關、注冊中心、配置中心等相關服務，可以被集群外部訪問；圖片對于測試「Tes」環境或者
大廠卷向扁平化

來源：新熵作者丨南枝編輯丨月見大廠職級不香了。俗話說，兵無常勢，水無常形，互聯網企業調整職級體系并不稀奇。7月13日，淘寶天貓集團啟動了近年來最大的人力制度改革，目前已形成一
攜眾多高端產品亮相ChinaJoy，小米帶來一場科技與人文的視聽盛宴

7月28日，全球數字娛樂領域最具知名度與影響力的年度盛會中國國際數碼互動娛樂展覽會（簡稱ChinaJoy）在上海新國際博覽中心盛大開幕。作為全球領先的科
機構稱Q2國內智能手機銷量同比下滑4% vivo份額重回第1

7月29日消息，根據市場調查機構Counterpoint Research公布的最新報告，2023年第2季度中國智能手機銷量同比下降4%，創新自2014年以來第2季度銷量新低。報
質感不錯！OPPO K11渲染圖曝光：旗艦IMX890傳感器首次下放

一直以來，OPPO K系列機型都保持著較為均衡的產品體驗，歷來都是2K價位的明星機型，去年推出的OPPO K10和OPPO K10 Pro兩款機型憑借各自的出色配置，堪稱有
聯想小新Pad Pro 12.6將要推出，搭載高通驍龍 870 處理器

聯想小新Pad Pro 12.6將于秋季新品會上推出，官方按照慣例直接在發布會前給出了機型的所有參數。聯想小新 Pad Pro 12.6 將搭載高通驍龍 870 處理器，重量為 5
親歷馬斯克血洗Twitter，硅谷的苦日子在后頭

文/劉哲銘　　編輯/李薇　　馬斯克再次揮下裁員大刀。　　美國時間11月14日，Twitter約4400名外包員工遭解雇，此次被解雇的員工的主要工作為內容審核等。此前，T

国产精品嫩草99av在线_一区在线视频观看_欧美高清一区_欧美日韩国产一区_99精品欧美一区二区三区_久久大香伊蕉在人线观看热2_一色屋精品视频在线观看网站_在线亚洲国产精品网站_亚洲区一区二区三区_你懂的视频一区二区

DDD 與 CQRS 才是黃金組合

1. CQRS 是什么？

2. 分層架構中的沖突

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

4. 模型層沖突與拆分

5. 倉庫層沖突與拆分

6. 數據層沖突與拆分

7. 小結

K60 Pro官方停產第三方瞬間漲價

0糖0卡0脂旭日森林仙草烏龍茶優惠：15瓶到手29元

K8S | Service服務發現

大廠卷向扁平化

攜眾多高端產品亮相ChinaJoy，小米帶來一場科技與人文的視聽盛宴

機構稱Q2國內智能手機銷量同比下滑4% vivo份額重回第1

質感不錯！OPPO K11渲染圖曝光：旗艦IMX890傳感器首次下放

聯想小新Pad Pro 12.6將要推出，搭載高通驍龍 870 處理器

親歷馬斯克血洗Twitter，硅谷的苦日子在后頭

最新推薦

猜你喜歡

熱門推薦

相關資訊