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