當(dāng)前位置：首頁 > 科技 > 軟件

DDD 與 CQRS 才是黃金組合

來源：責(zé)編：時(shí)間：2023-08-20 23:17:18 10506觀看

導(dǎo)讀在日常工作中，你是否也遇到過下面幾種情況：使用一個(gè)已有接口進(jìn)行業(yè)務(wù)開發(fā)，上線后出現(xiàn)嚴(yán)重的性能問題，被老板當(dāng)眾質(zhì)疑：“你為什么不使用緩存接口，這個(gè)接口全部走數(shù)據(jù)庫，這怎么能抗住！”開發(fā)一個(gè)后臺(tái)管理功能，業(yè)務(wù)反饋說數(shù)據(jù)一直

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

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

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

1. CQRS 是什么？

CQRS 是 Command Query Responsibility Segregation 得簡稱，簡單理解就是對(duì) “寫”（Command）和 “讀” （Query）操作進(jìn)行分離。反應(yīng)快的同學(xué)會(huì)說：“也不是什么高深技術(shù)嗎，不就是數(shù)據(jù)庫的讀寫分離嗎？”

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

CRQS 既是一種流行的業(yè)務(wù)架構(gòu)，又是一種設(shè)計(jì)思維。

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

CQRS的目的是降低整個(gè)系統(tǒng)的復(fù)雜性，那它背后的邏輯是什么？

假設(shè)，在一個(gè)系統(tǒng)中：

Command 的復(fù)雜性為 M
Query 的復(fù)雜性為 N

如果使用同一套模型來處理 Command 和 Query，那在極端情況下，系統(tǒng)的復(fù)雜性為 M * N，因?yàn)閮烧呦嗷ビ绊懀{(diào)整一方的同時(shí)要時(shí)刻關(guān)注對(duì)另一方的影響。

圖片

這種“你中有我，我中有你”的設(shè)計(jì)方式，“兩者的相互影響”成為系統(tǒng)最為復(fù)雜之處，大量精力消耗在“排查影響”，而非最有價(jià)值的設(shè)計(jì)和編碼。

如果，將 Command 和 Query 徹底分離，系統(tǒng)的復(fù)雜性變成 M + N。Command 的變更不會(huì)影響 Query，而 Query 的修改也不會(huì)影響 Command。

圖片

當(dāng)然，以上兩個(gè)極端在實(shí)際工作中也很少見，通常系統(tǒng)的復(fù)雜性介于兩者之間。

圖片

這只是從理論進(jìn)行推導(dǎo)，在實(shí)際工作中隨處可見的“沖突”也是對(duì)“拆分”的一種暗示。

2. 分層架構(gòu)中的沖突

以最常見的分層架構(gòu)進(jìn)行介紹，具體如下：

圖片

如圖所示，將系統(tǒng)分成5層，每層的含義如下：

Web 接入層。主要用于處理系統(tǒng)輸入，對(duì)輸入信息進(jìn)行驗(yàn)證，調(diào)用應(yīng)用服務(wù)完成業(yè)務(wù)操作，對(duì)結(jié)果進(jìn)行轉(zhuǎn)換，最終返回給調(diào)用方；
應(yīng)用服務(wù)層。主要處理業(yè)務(wù)流程編排，從倉庫中獲取領(lǐng)域?qū)ο螅瑘?zhí)行領(lǐng)域模型的業(yè)務(wù)操作，將最新的對(duì)象狀態(tài)通過倉庫同步到數(shù)據(jù)存儲(chǔ)引擎，并對(duì)外發(fā)布領(lǐng)域事件；
領(lǐng)域?qū)印I(yè)務(wù)邏輯的承載點(diǎn)，是業(yè)務(wù)價(jià)值的集中體現(xiàn)，通常構(gòu)建于面向?qū)ο笤O(shè)計(jì)之上，基于封裝、繼承、多態(tài)等特性保障業(yè)務(wù)邏輯的復(fù)用性和擴(kuò)展性；
倉庫層。主要用于數(shù)據(jù)訪問，向上為應(yīng)用服務(wù)提供數(shù)據(jù)操作服務(wù)，向下屏蔽各類存儲(chǔ)引擎的差異；
數(shù)據(jù)層。主要用于數(shù)據(jù)保存和檢索，常見的數(shù)據(jù)存儲(chǔ)引擎全部屬于這一層，比如 MySQL、Redis、ES 等；

其實(shí)，分層架構(gòu)本身也是一種“拆分”，將不同的關(guān)注點(diǎn)封裝在不同的層次。但除了橫向分層，還可以基于 CQRS 對(duì)其進(jìn)行縱向拆分，也就是將每個(gè)層的組件拆分為 Command 和 Query 兩部分。

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

3. 應(yīng)用服務(wù)層沖突與拆分

應(yīng)用服務(wù)層拆分就是將一個(gè)應(yīng)用服務(wù)拆分為 CommandService 和 QueryService 兩組。

圖片

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

	CommandService	QueryService
依賴組件不同	ValidateService 驗(yàn)證服務(wù)；LazyLoaderFactory 延遲加載服務(wù)；CommandRepository 不帶緩存的倉庫；EventPublisher 事件發(fā)表器	QueryRepository 帶緩存功能的倉庫；JoinService 數(shù)據(jù)聚合服務(wù)；Converter 數(shù)據(jù)轉(zhuǎn)換服務(wù)
核心流程不同	驗(yàn)證、加載、業(yè)務(wù)操作、同步、發(fā)布事件	驗(yàn)證、加載、數(shù)據(jù)組裝、轉(zhuǎn)換
功能加強(qiáng)不同	主要是事務(wù)管理器	主要是緩存組件

回想開篇時(shí)提到的場景，完成應(yīng)用層拆分，就不在為使用錯(cuò)組件而煩惱：

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

除此之外，針對(duì)統(tǒng)一的操作流程，還可以進(jìn)一步抽象來消除重復(fù)的“模板代碼”，比如：

引入“模板方法設(shè)計(jì)模式” 以達(dá)到核心邏輯的復(fù)用

抽象出 BaseCommandService 和 BaseQueryService 兩個(gè)父類用于統(tǒng)一核心流程

子類實(shí)現(xiàn) BaseCommandService 和 BaseQueryService 的抽象方法完成功能擴(kuò)展

基于“約定優(yōu)于配置” 使用 Proxy 模型，只定義接口不寫實(shí)現(xiàn)代碼
按規(guī)范定義 CommandService 和 QueryService 接口，通過注解完成相關(guān)配置
自動(dòng)生成 Proxy 實(shí)現(xiàn)類，完成流程編排

4. 模型層沖突與拆分

模型層是系統(tǒng)的核心，它的設(shè)計(jì)直接影響整個(gè)系統(tǒng)的質(zhì)量。作為承接業(yè)務(wù)邏輯的核心，比較流程的實(shí)現(xiàn)策略包括：

DDD 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，其核心是使用面向?qū)ο蟮母呒?jí)特性（封裝、繼承、多態(tài)、組合等）來進(jìn)行設(shè)計(jì)，非常適合復(fù)雜的業(yè)務(wù)場景。其體現(xiàn)就是存在很多高內(nèi)聚低耦合的對(duì)象組（聚合根），業(yè)務(wù)邏輯由這些小對(duì)象相互協(xié)作共同完成；
事務(wù)腳本，使用過程式思維，將數(shù)據(jù)操作編織到流程中，比較適合并不復(fù)雜的業(yè)務(wù)場景。其體現(xiàn)就是存在很多“上帝 Service”，Service 中存在很多非常長的方法，業(yè)務(wù)邏輯由這些方法完成；

關(guān)于哪個(gè)才是最優(yōu)解，網(wǎng)上已經(jīng)爭論多年，最終也沒有結(jié)論。但我始終認(rèn)為“沒有業(yè)務(wù)場景就討論方案，就是在耍流氓”。

從不同應(yīng)用場景出發(fā)便可得到如下結(jié)論：

Command 場景需要保障嚴(yán)謹(jǐn)?shù)臉I(yè)務(wù)邏輯，通常復(fù)雜性偏高，所以DDD 是最優(yōu)解
Query 場景需要更靈活的數(shù)據(jù)組裝能力作為支持，通常比較簡單，所以事務(wù)腳本是最優(yōu)解

我經(jīng)常說：“最簡單的“寫”也是復(fù)雜，最復(fù)雜的“讀”也是簡單”，其背后邏輯是基于對(duì) Command 和 Query 的場景判斷。

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

圖片

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

Agg 也就是 DDD 中聚合根，主要用于處理復(fù)雜的 Command 邏輯，由具有大量業(yè)務(wù)操作的"富對(duì)象"構(gòu)成；
View 是標(biāo)準(zhǔn)的 POJO，主要充當(dāng) Query 結(jié)果對(duì)象，典型的“貧血對(duì)象”，僅作為數(shù)據(jù)的載體，根據(jù)展示需求對(duì)數(shù)據(jù)進(jìn)行組裝；
View 沒有自己的 Repository，只能依賴 CommandRepository 獲取數(shù)據(jù)，Converter 組件負(fù)責(zé)將 Agg 模型轉(zhuǎn)換為 View 模型。

這塊是拆分的重點(diǎn)，為了方便理解，簡單舉個(gè)例子：

比如在電商的訂單模塊：

生單流程，由 Order 作為聚合根對(duì)內(nèi)部 OrderItem 和 PayInfo 進(jìn)行統(tǒng)一協(xié)調(diào)
訂單列表頁，只需展示 Order 和 User 信息
訂單詳情，需要展示Order、User、Address、OrderItem、PayInfo、Product等信息

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

此時(shí)，應(yīng)該根據(jù)場景對(duì)模型進(jìn)行拆分：

OrderBO 以 DDD 方式進(jìn)行建模，對(duì)外提供統(tǒng)一的業(yè)務(wù)操作，對(duì)內(nèi)協(xié)調(diào) OrderItem 和 PayInfo 等多個(gè)實(shí)體對(duì)象；
OrderListVO 以 POJO 方式進(jìn)行建模，屬性中包含 Order 和 User 信息；
OrderDetailVO 以 POJO 方式進(jìn)行建模，屬性中包括 Order、User、Address、OrderItem、PayInfo、Product 等信息；

三個(gè)模型相互獨(dú)立，互不影響。

當(dāng)然，由于使用統(tǒng)一的 Repository 還需提供對(duì)應(yīng) VO 的 Converter：

OrderListVOConverter 將 OrderBO 轉(zhuǎn)換為 OrderListVO 對(duì)象
OrderDetailVOConverter 將 OrderBO 轉(zhuǎn)化為 OrderDetailVO 對(duì)象

5. 倉庫層沖突與拆分

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

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

倉庫拆分后整體架構(gòu)如下：

圖片

倉庫拆分具有以下特點(diǎn)：

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

6. 數(shù)據(jù)層沖突與拆分

數(shù)據(jù)層拆分是最重要的拆分，提到分離第一反應(yīng)也是“數(shù)據(jù)庫主從分離”。

數(shù)據(jù)層拆分的本質(zhì)是：各種數(shù)據(jù)存儲(chǔ)引擎的最佳應(yīng)用場景相差巨大，讀和寫優(yōu)化往往存在矛盾。

仍舊以最常見的數(shù)據(jù)庫為例：

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

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

數(shù)據(jù)層拆分后架構(gòu)如下：

圖片

該模型具有以下特點(diǎn)：

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

工作在應(yīng)用層基于領(lǐng)域事件的數(shù)據(jù)同步，如圖所示
工作在數(shù)據(jù)層基于log的數(shù)據(jù)同步，如 MySQL 的主從同步、Canal2XX 等

數(shù)據(jù)層拆分是大型系統(tǒng)最終的歸宿，仍舊以訂單系統(tǒng)為例：

訂單作為一致性要求極高的系統(tǒng)，Command 側(cè)首選仍舊為具有 ACID 的關(guān)系型數(shù)據(jù)庫，哪怕是分庫分表底層存儲(chǔ)仍舊不變；
為了滿足高性能查詢需求，需要在 Query 側(cè)引入 Redis 作為分布式緩存對(duì)訪問進(jìn)行加速；
為了滿足后臺(tái)復(fù)雜且多維度的業(yè)務(wù)查詢，需要在 Query 側(cè)引入 ES 為全文檢索進(jìn)行加速；
為了滿足各種實(shí)時(shí)報(bào)表需求，需要在 Query 側(cè)引入 TiDB 以滿足海量數(shù)據(jù)的實(shí)時(shí)檢索；

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

7. 小結(jié)

“拆分”是“分離關(guān)注點(diǎn)”的重要手段之一。拆分的目的是將問題進(jìn)行歸類，然后采取有針對(duì)性的手段更好的解決問題。

CQRS 作為一種架構(gòu)，將業(yè)務(wù)系統(tǒng)不同部分進(jìn)行歸類，接下來需要為 Command 和 Query 尋找最優(yōu)解決方案：

Command，以 DDD 作為理論基礎(chǔ)將戰(zhàn)術(shù)模型中最佳實(shí)戰(zhàn)進(jìn)行落地，包括

聚合設(shè)計(jì)

倉庫設(shè)計(jì)

LazyLoad + Context 模式

業(yè)務(wù)驗(yàn)證

領(lǐng)域事件

…

Query，以數(shù)據(jù)檢索和組裝作為核心能力，設(shè)計(jì)留給開發(fā)人員，實(shí)現(xiàn)留給框架，包括：

QueryObject 查詢對(duì)象模式
內(nèi)存 Join 模式
寬表&冗余表模式

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

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com

上一篇： H5-Dooring可視化頁面制作神器測評(píng)總結(jié)

下一篇：資損防控技術(shù)體系簡介及實(shí)踐

標(biāo)簽：

熱門焦點(diǎn)

K60 Pro官方停產(chǎn) 第三方瞬間漲價(jià)

雖然沒有官方宣布，但Redmi的一些高管也已經(jīng)透露了，Redmi K60 Pro已經(jīng)停產(chǎn)且不會(huì)補(bǔ)貨，這一切都是為了即將到來的K60 Ultra鋪路，屬于廠家的正常操作。但有意思的是該機(jī)在停產(chǎn)之后
MIX Fold3包裝盒泄露新機(jī)本月登場

小米的全新折疊屏旗艦MIX Fold3將于本月發(fā)布，近日該機(jī)的真機(jī)包裝盒在網(wǎng)上泄露。從圖上來看，新的MIX Fold3包裝盒在外觀設(shè)計(jì)方面延續(xù)了之前的方案，變化不大，這也是目前小米旗艦
俄羅斯：將審查iPhone等外國公司設(shè)備保數(shù)據(jù)安全

iPhone和特斯拉都屬于在各自領(lǐng)域領(lǐng)頭羊的品牌，推出的產(chǎn)品也也都是數(shù)一數(shù)二的，但對(duì)于一些國家而言，它們的產(chǎn)品可靠性和安全性還是在限制范圍內(nèi)。近日，俄羅斯聯(lián)邦通信、信息技術(shù)
石頭自清潔掃拖機(jī)器人G10S評(píng)測：多年黑科技集大成之作懶人終極福音

科技圈經(jīng)常能看到一個(gè)詞叫“縫合怪”，用來形容那些把好多功能或者外觀結(jié)合在一起的產(chǎn)品，通常這樣的詞是貶義詞，但如果真的是產(chǎn)品縫合的好、縫合的實(shí)用的話，那它就成了中性詞，今
2023年Q2用戶偏好榜：12+256G版本成新主流

3月份的性能榜、性價(jià)比榜和好評(píng)榜之后，就要輪到2023年的第二季度偏好榜了，上半年的新機(jī)潮已經(jīng)過去，最明顯的肯定就是大內(nèi)存和存儲(chǔ)的機(jī)型了，另外部分中端機(jī)也取消了屏幕塑料支架
十個(gè)可以手動(dòng)編寫的 JavaScript 數(shù)組 API

JavaScript 中有很多API，使用得當(dāng)，會(huì)很方便，省力不少。你知道它的原理嗎? 今天這篇文章，我們將對(duì)它們進(jìn)行一次小總結(jié)。現(xiàn)在開始吧。1.forEach()forEach()用于遍歷數(shù)組接收一參
猿輔導(dǎo)與新東方的兩種“歸途”

作者｜卓心月出品｜零態(tài)LT（ID：LingTai_LT）如何成為一家偉大企業(yè)？答案一定是對(duì)“勢”的把握，這其中最關(guān)鍵的當(dāng)屬對(duì)企業(yè)戰(zhàn)略的制定，且能夠站在未來看現(xiàn)在，即使這其中的
2299元起！iQOO Pad開啟預(yù)售：性能最強(qiáng)天璣平板

5月23日，iQOO如期舉行了新品發(fā)布會(huì)，除了首發(fā)安卓最強(qiáng)旗艦處理器的iQOO Neo8系列新機(jī)外，還在發(fā)布會(huì)上推出了旗下首款平板電腦——iQOO Pad，其搭載了天璣
回歸OPPO兩年，一加贏了銷量，輸了品牌

成為OPPO旗下主打性能的先鋒品牌后，一加屢創(chuàng)佳績。今年618期間，一加手機(jī)全渠道銷量同比增長362%，憑借一加 11、一加 Ace 2、一加 Ace 2V三款爆品，一加

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

DDD 與 CQRS 才是黃金組合

1. CQRS 是什么？

2. 分層架構(gòu)中的沖突

3. 應(yīng)用服務(wù)層沖突與拆分

4. 模型層沖突與拆分

5. 倉庫層沖突與拆分

6. 數(shù)據(jù)層沖突與拆分

7. 小結(jié)

K60 Pro官方停產(chǎn) 第三方瞬間漲價(jià)

MIX Fold3包裝盒泄露新機(jī)本月登場

俄羅斯：將審查iPhone等外國公司設(shè)備保數(shù)據(jù)安全

石頭自清潔掃拖機(jī)器人G10S評(píng)測：多年黑科技集大成之作懶人終極福音

2023年Q2用戶偏好榜：12+256G版本成新主流

十個(gè)可以手動(dòng)編寫的 JavaScript 數(shù)組 API

猿輔導(dǎo)與新東方的兩種“歸途”

2299元起！iQOO Pad開啟預(yù)售：性能最強(qiáng)天璣平板

回歸OPPO兩年，一加贏了銷量，輸了品牌

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊