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