實踐 DDD 領(lǐng)域驅(qū)動設(shè)計

說明領(lǐng)域驅(qū)動設(shè)計最近又火了。概念不斷被提及，但是相信對于像筆者一樣的很多開發(fā)者對于其如何應(yīng)用都一頭霧水。正如《實現(xiàn)領(lǐng)域驅(qū)動設(shè)計》中作者提到的不同公司的業(yè)務(wù)能力開發(fā)能力和成熟度不一樣，DDD為了解決復(fù)雜業(yè)務(wù)為生，并不適合所有的軟件項目，對于很多初創(chuàng)公司而言，業(yè)務(wù)本身就是模糊的，只是需要做出一個MVP（最小可行性產(chǎn)品）來試探商業(yè)模式，采用ddd顯得過〃重”了一點，反而給團隊成員帶來額外的負擔(dān)，所以團隊管理者首先應(yīng)該關(guān)注的是軟件系統(tǒng)是否得做出DDD投入。不過不管黑貓白貓，能抓到老鼠就是好貓。我們以電商業(yè)務(wù)來演練和實踐ddd的部分理論，并解釋ddd的概念。戰(zhàn)略設(shè)計階段領(lǐng)域:即業(yè)務(wù)是屬于哪塊，電商領(lǐng)域，保險領(lǐng)域，零售領(lǐng)域，又可細化分為子領(lǐng)域。如電商下（訂單交易領(lǐng)域、庫存領(lǐng)域、會員領(lǐng)域、物流領(lǐng)域....）領(lǐng)域?qū)＜?一般指熟悉對應(yīng)領(lǐng)域的產(chǎn)品經(jīng)理項目經(jīng)理子域:子域可細分為核心子域、通用子域和支撐子域，簡單理解為哪部分是比較核心的就可稱作核心子域，哪些功能偏邊緣化叫支撐域?；ヂ?lián)網(wǎng)公司的敏捷開發(fā)模式的產(chǎn)品研發(fā)流程從收集需求、 PRD評審、技術(shù)模塊拆分這些前期流程。而戰(zhàn)略設(shè)計即在這個階段完成，顧名思義側(cè)重于從宏觀上對業(yè)務(wù)進行拆分，和對未來走向的預(yù)測。DDD的目的是為了領(lǐng)域?qū)＜腋玫嘏c開發(fā)進行溝通合作，使得代碼更好地傳達業(yè)務(wù)規(guī)則。最初的需求方可能會提一些凌亂的需求。為了更好地傳達規(guī)則，領(lǐng)域?qū)＜覍⑿枨笳咸崛〕鲱I(lǐng)域的概念，技術(shù) /項目管理者一起劃分好子域和限界上下文。各方統(tǒng)一所謂的通用語言并在以后的協(xié)作中使用。比如電商業(yè)務(wù)中雙方約定好中商家用戶和買家用戶的概念，用戶和賬戶的概念，交易訂單和支付訂單、物流訂單、售后訂單的概念，以實現(xiàn)后期溝通順暢。最終產(chǎn)出:劃分出了哪些子領(lǐng)域、上下文映射圖是怎樣的。貼一個電商業(yè)務(wù)的上下文映射圖（下單交易上下文為下游，其他皆為上游）：而各個上下文的交互方式，即集成限界上下文的方式其實就是我們常說的系統(tǒng)交互方式:RPC調(diào)用、REST接口調(diào)用、消息隊列通信。怎么理解限界上下文和子域的關(guān)系?限界上下文:是一個顯示邊界，領(lǐng)域模型即存在于這個邊界之內(nèi)。在邊界內(nèi)，通用語言有特定明確的意義。ps:是不是覺得每個字都認(rèn)得，但是不知道表達了什么意思....在理解限界上下文和子域上確實有點費勁。筆者當(dāng)時的疑惑主要是：為什么要用上下文映射圖而不是子域交互圖，子域劃分出來不就說明邊界已經(jīng)明確了么，為什么還專門搞一個限界上下文的概念。關(guān)于限界上下文，貼一下個人理解：接下來要咬文嚼字一些了。1、 從〃限界”二字來說。限界上下文明確了業(yè)務(wù)范圍和職責(zé)邊界。針對上面問題“子域中不是已經(jīng)有邊界的概念了么”。可以思考一個有意思的事，子域有邊界，還是說因為有了邊界才有子域。聽到過一個非常到位的類比如果沒有細胞壁，如何定義細胞質(zhì)？2、 從“上下文”來說。上下文關(guān)注的是兩個系統(tǒng)交互時的環(huán)境，或者說語境。舉個例子:小學(xué)是一個子域，中學(xué)是一個子域。升學(xué)這個事件動作則要上下文表達。通用語言要在限界上下文（語境）中保證其明確意義。舉個例子，商家管理上下文中，我們（平臺）說的用戶指的是商家而不是買家，支付上下文中，我們以支付單為核心，語境無需引入物流單、庫存等詞匯。通常來說，我們可以近似地認(rèn)為子域和限界上下文一對應(yīng)的。戰(zhàn)術(shù)設(shè)計階段截止到此，我們已經(jīng)劃分好了子域，對開發(fā)人員來說，已經(jīng)拆分好了項目。各個團隊可以針對自己的子域進行獨立開發(fā)了。對于 ddd而言，我們開始進行戰(zhàn)術(shù)設(shè)計階段。戰(zhàn)略設(shè)計關(guān)心做什么，戰(zhàn)術(shù)設(shè)計則更關(guān)心技術(shù)實現(xiàn)細節(jié)，即:怎么做。先說下ddd中推薦的六邊形架構(gòu)：這里要吐槽一下六邊形架構(gòu)這個命名，搞得好像有六個什么東西一樣。其實只是根據(jù)視覺形狀起的名。現(xiàn)在叫端口與適配器架構(gòu)。轉(zhuǎn)換一下是這樣的嚴(yán)格分層架構(gòu):某層只能與直接位于其下方的層發(fā)生耦合松散分層架構(gòu)：允許上方層可以與任意下方層發(fā)生耦合。這里采用松散分層架構(gòu)。也可按依賴倒置原則，基礎(chǔ)層依賴領(lǐng)域?qū)拥囊恍〇|西（常見的就是實體Entity）適配器層:負責(zé)接口轉(zhuǎn)換，即是最外層請求處理類，將外部請求轉(zhuǎn)化為內(nèi)部 API能理解的輸入。對于REST接口可能是一個controller類；對于dubbo調(diào)用來說是開放出去的provider服務(wù)類;對于grpc調(diào)用來說，是protobuf請求對象轉(zhuǎn)換處理類；對于消息機制來說，對應(yīng)的是消息的監(jiān)聽器如此采用端口適配器模式，可以不影響內(nèi)部服務(wù)，只需在適配器層進行增改。盡管大家不知道六邊形架構(gòu)的定義，但相信很多人是這樣做的。無須螯述。應(yīng)用層:負責(zé)協(xié)調(diào)領(lǐng)域?qū)拥慕涌趯崿F(xiàn)前端展示或返回需要。領(lǐng)域?qū)?定義領(lǐng)域?qū)嶓w和邏輯。包括實體、值對象、領(lǐng)域服務(wù)、領(lǐng)域事件、資源庫。基礎(chǔ)層:如數(shù)據(jù)庫相關(guān)。實體和值對象實體:有唯一業(yè)務(wù)標(biāo)識有自己的業(yè)務(wù)屬性和行為屬性可變，有自己的生命周期對象河以有唯一業(yè)務(wù)標(biāo)識有自己的業(yè)務(wù)屬性和行為旦定義不可改變二者的關(guān)系可總結(jié)為:值對象關(guān)心對象是什么樣的，實體側(cè)重描述對象是哪提到有自己的業(yè)務(wù)屬性和行為這塊，想想這不就是我們年輕時說的面向?qū)ο缶幊痰乃枷氪a?但是回顧一下會發(fā)現(xiàn)，這個思想好像被很多人拋諸腦后很久了，定義的對象類都成了一個個的pojo，只有屬性和屬性對應(yīng)getter和seter方法，也就是ddd中所說的失血模型。失血模型:只含屬性和對應(yīng)的getter/setter方法，無業(yè)務(wù)處理邏輯貧血模型:包含不依賴持久化的部分領(lǐng)域邏輯，依賴持久的邏輯被放在領(lǐng)域服務(wù)層。充血模型:絕大數(shù)業(yè)務(wù)邏輯都放在其中，包括持久化邏輯。少數(shù)不適合的邏輯被提取出來放在領(lǐng)域服務(wù)層中。脹血模型:主張不需要領(lǐng)域服務(wù)層，把一些業(yè)務(wù)邏輯都放在模型對象中處理領(lǐng)域服務(wù)脹血模型主張把所有的業(yè)務(wù)邏輯放在模型中處理，但是事實上有些邏輯并不是適合放在某個領(lǐng)域?qū)ο笾刑幚怼１热?、 領(lǐng)域?qū)ο箝g的轉(zhuǎn)換2、 某些場景下需要多個領(lǐng)域?qū)ο笞鳛檩斎胫?，結(jié)果產(chǎn)生一個值對象。區(qū)別于應(yīng)用層的服務(wù)，領(lǐng)域服務(wù)處理的是業(yè)務(wù)邏輯。應(yīng)用層負責(zé)對領(lǐng)域服務(wù)處理結(jié)果進行渲染和組裝返回給前端。ps:針對查詢類的操作，建議作為應(yīng)用層的查詢服務(wù)單獨拎出來，因為查詢嘗嘗涉及到多個維度的查詢，或把多個領(lǐng)域?qū)ο蟮牟樵兘Y(jié)果組裝成一個返回值對象。舉個栗子:訂單領(lǐng)域需要向商家（PC端）和買家（APP端），商家端按發(fā)貨條件時間查詢所有買家的訂單，操作發(fā)貨處理售后等流程。買家端完成下單、查詢個人訂單。在應(yīng)用層我們抽象三個應(yīng)用處理出來，公用的查詢應(yīng)用、商家端應(yīng)用（關(guān)聯(lián)商家權(quán)限控制上下文）、買家端應(yīng)用（關(guān)聯(lián)買家權(quán)限控制上下文）。領(lǐng)域事件領(lǐng)域事件即領(lǐng)域業(yè)務(wù)周期中一些關(guān)鍵行為，關(guān)鍵的定義是其他地方需要依賴此事件推送業(yè)務(wù)流轉(zhuǎn)。如訂單被支付這個事件，需要觸發(fā)庫存扣減、商家待結(jié)算賬戶余額增加等操作。關(guān)于領(lǐng)域事件處理方法:跨子域處理常用消息隊列發(fā)布/訂閱模式，同項目處理常用注冊事件監(jiān)聽器處理。不多描述。聚合和資源庫領(lǐng)域?qū)ο笾g常常有依賴關(guān)系。比如主訂單-子訂單（商品）項，子訂單依附于主訂單存在，二者的關(guān)系稱作聚合，主訂單作為聚合根.@DatapublicclassTradeOrderEntity{//訂單號StringorderNo;//商品詳情ListorderltemDetails;//...}我們通過為每一個聚合選擇一個根，并通過根來控制所有對邊界內(nèi)的對象的訪問。外部對象只能持有根的引用；由于根控制了訪問，因此我們無法繞過它去修改內(nèi)部元素。所以在ddd中，資源庫Repository是面向聚合根操作的，可對多個dao對象的組合使用。@RepositorypublicclassTradeOrderRepository{@AutowiredTradeOrderMappertradeOrderMapper;@AutowiredOrderItemDetailMapperorderltemDetailMapp