團(tuán)隊(duì)里老有人問(wèn)DDD到底怎么落地代碼和業(yè)務(wù)始終對(duì)不上賬微服務(wù)拆了一堆又變成分布式大泥球這個(gè)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)Domain-Driven DesignDDD看著高大上真上手卻總覺(jué)得隔著一層紙。這篇文章我就把DDD從概念到落地掰開(kāi)揉碎講講那些書(shū)里不會(huì)細(xì)寫(xiě)的坑和實(shí)操經(jīng)驗(yàn)。不管你是剛聽(tīng)說(shuō)DDD這個(gè)名字想了解一下還是已經(jīng)在項(xiàng)目里試過(guò)但卡在某一步這篇文章都會(huì)對(duì)你有用——我會(huì)用真實(shí)項(xiàng)目里踩過(guò)的坑、總結(jié)出來(lái)的套路把戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)怎么結(jié)合、代碼怎么組織、常見(jiàn)問(wèn)題怎么排查都講透。1. 內(nèi)容整體設(shè)計(jì)與思路拆解1.1 為什么DDD總在“聽(tīng)過(guò)”和“會(huì)用”之間卡殼我見(jiàn)過(guò)太多團(tuán)隊(duì)學(xué)DDD的路徑先買(mǎi)本藍(lán)皮書(shū)翻兩章然后開(kāi)會(huì)討論“聚合”和“值對(duì)象”討論了兩個(gè)月還是不知道代碼放哪個(gè)包最后又回到面向數(shù)據(jù)庫(kù)寫(xiě)代碼的老路上。問(wèn)題不全在學(xué)習(xí)者身上DDD這個(gè)概念本身確實(shí)容易讓人覺(jué)得飄。DDD說(shuō)起來(lái)其實(shí)只有兩件事理清業(yè)務(wù)邊界和讓代碼表達(dá)業(yè)務(wù)。理清業(yè)務(wù)邊界是戰(zhàn)略設(shè)計(jì)對(duì)應(yīng)限界上下文、上下文映射、防腐層這些東西讓代碼表達(dá)業(yè)務(wù)是戰(zhàn)術(shù)設(shè)計(jì)對(duì)應(yīng)實(shí)體、值對(duì)象、聚合、領(lǐng)域服務(wù)、領(lǐng)域事件這些模式。很多團(tuán)隊(duì)卡殼是因?yàn)橐簧蟻?lái)就扎進(jìn)戰(zhàn)術(shù)模式里整天糾結(jié)實(shí)體和值對(duì)象怎么區(qū)分忘了DDD最值錢(qián)的部分其實(shí)在最開(kāi)始。拿我之前參與過(guò)一個(gè)訂單系統(tǒng)的模擬項(xiàng)目X來(lái)說(shuō)當(dāng)時(shí)團(tuán)隊(duì)成員對(duì)“訂單”這個(gè)詞的理解都不一致。運(yùn)營(yíng)說(shuō)的訂單是用戶付款的記錄倉(cāng)儲(chǔ)說(shuō)的訂單是要發(fā)貨的單據(jù)財(cái)務(wù)說(shuō)的訂單是收入確認(rèn)的依據(jù)。如果大家不先把“訂單”在不同場(chǎng)景下的含義厘清直接在代碼里建一個(gè)全字段大Order表后續(xù)所有需求都會(huì)在這個(gè)大泥球上不斷打補(bǔ)丁。DDD解決問(wèn)題的思路是不先從數(shù)據(jù)結(jié)構(gòu)出發(fā)而是從業(yè)務(wù)事件和業(yè)務(wù)角色出發(fā)把整個(gè)系統(tǒng)按業(yè)務(wù)邊界切分成若干個(gè)獨(dú)立的小世界——也就是限界上下文。每個(gè)小世界內(nèi)部有自己的語(yǔ)言和數(shù)據(jù)模型小世界之間通過(guò)明確接口通信。這樣不同部門(mén)對(duì)“訂單”的不同理解就可以被顯式地建模成不同上下文里的不同模型而不是拼湊在一張表里。1.2 戰(zhàn)略設(shè)計(jì)先于技術(shù)選型很多團(tuán)隊(duì)在做架構(gòu)評(píng)審時(shí)喜歡一開(kāi)始就對(duì)技術(shù)棧爭(zhēng)論不休用MySQL還是PostgreSQL消息隊(duì)列用這個(gè)還是那個(gè)服務(wù)發(fā)現(xiàn)用哪個(gè)組件。這些當(dāng)然是需要定的但不應(yīng)該是DDD的起點(diǎn)。正確的順序應(yīng)該倒過(guò)來(lái)先完成業(yè)務(wù)建模畫(huà)出限界上下文和上下文映射關(guān)系再根據(jù)業(yè)務(wù)邊界來(lái)決定系統(tǒng)怎么拆。比如訂單上下文和庫(kù)存上下文之間是防腐層關(guān)系還是共享內(nèi)核關(guān)系直接決定了兩個(gè)服務(wù)之間是走接口調(diào)用還是共享數(shù)據(jù)庫(kù)也決定了后續(xù)的團(tuán)隊(duì)分工和發(fā)布節(jié)奏。我自己做DDD項(xiàng)目有一條鐵律前兩周不允許寫(xiě)一行代碼所有人都在做業(yè)務(wù)分析、事件風(fēng)暴、術(shù)語(yǔ)表梳理、邊界劃分。很多程序員一開(kāi)始不適應(yīng)覺(jué)得在浪費(fèi)時(shí)間可一旦邊界畫(huà)清楚了后面寫(xiě)代碼的效率非常快改動(dòng)一個(gè)業(yè)務(wù)規(guī)則不需要牽一發(fā)動(dòng)全身。該快的時(shí)候反而不能急著寫(xiě)代碼這個(gè)反直覺(jué)的順序就是DDD和傳統(tǒng)以數(shù)據(jù)表為起點(diǎn)的設(shè)計(jì)最大的不同。2. 核心概念解構(gòu)與實(shí)操要點(diǎn)2.1 實(shí)體和值對(duì)象這兩個(gè)概念決定了數(shù)據(jù)建模的格局DDD的戰(zhàn)術(shù)設(shè)計(jì)里最基礎(chǔ)也最重要的選擇就是模型里哪些東西是實(shí)體哪些是值對(duì)象。實(shí)體是有唯一標(biāo)識(shí)、有生命周期、需要被追蹤的東西。比如一個(gè)訂單它有訂單號(hào)狀態(tài)從待支付變成已支付再變成已發(fā)貨這個(gè)過(guò)程里訂單一直存在必須能隨時(shí)找到它。值對(duì)象則不同它描述的是某個(gè)維度上的特征不需要唯一標(biāo)識(shí)兩個(gè)值對(duì)象如果屬性相同就是同一個(gè)東西。比如金額50元這個(gè)對(duì)象不存在“兩個(gè)不同的50元”這種說(shuō)法。這兩個(gè)概念放到傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)里看會(huì)非常清楚實(shí)體對(duì)應(yīng)有主鍵的表值對(duì)象通?？梢耘c實(shí)體共享一張表做嵌入式存儲(chǔ)或者被序列化存儲(chǔ)也可以獨(dú)立成表但沒(méi)有業(yè)務(wù)主鍵只有值。實(shí)操時(shí)有一個(gè)很實(shí)用的判斷技巧如果兩個(gè)對(duì)象被你放進(jìn)同一個(gè)集合比較時(shí)你期望它們“相等”的判斷標(biāo)準(zhǔn)是“所有屬性都相等”那這就是值對(duì)象如果期望“唯一標(biāo)識(shí)一樣就相等”那這就是實(shí)體。比如訂單明細(xì)里的商品名稱、單價(jià)這些內(nèi)容如果訂單改了舊的明細(xì)內(nèi)容作廢了新的明細(xì)就是一個(gè)新的值對(duì)象不需要給它單獨(dú)搞一個(gè)明細(xì)ID去追蹤歷史。這里我再補(bǔ)充一個(gè)踩過(guò)的坑。我們?cè)?jīng)想當(dāng)然地把訂單明細(xì)設(shè)計(jì)成實(shí)體給每個(gè)明細(xì)行加了自增主鍵結(jié)果發(fā)現(xiàn)大量業(yè)務(wù)邏輯被吸引到了明細(xì)這個(gè)實(shí)體上修改數(shù)量、拆分行、記錄贈(zèng)品來(lái)源。這些操作讓明細(xì)模型變得越來(lái)越重但業(yè)務(wù)上根本不需要追溯明細(xì)行的狀態(tài)變化。后來(lái)把它改成值對(duì)象集合訂單只聚合一組快照數(shù)據(jù)整個(gè)模型輕了不止一個(gè)量級(jí)改數(shù)量就是替換集合里的一個(gè)值對(duì)象用不到任何狀態(tài)流轉(zhuǎn)。2.2 聚合設(shè)計(jì)把一致性邊界劃在正確的位置聚合是DDD戰(zhàn)術(shù)設(shè)計(jì)里最難的環(huán)節(jié)難點(diǎn)不在于概念本身而在于約束業(yè)務(wù)規(guī)則和一致性范圍時(shí)要敢于取舍。聚合要解決的核心問(wèn)題是哪些對(duì)象必須被作為一個(gè)整體來(lái)更新如果訂單狀態(tài)變?yōu)椤耙讶∠蹦怯唵卫锩娴乃忻骷?xì)、配送信息、支付信息是否都要同時(shí)滿足某個(gè)不變量如果能接受稍后一致那么把關(guān)聯(lián)對(duì)象拆成獨(dú)立聚合是合理的如果不能接受就必須讓它們待在同一個(gè)聚合內(nèi)通過(guò)同一個(gè)事務(wù)保證一致性。聚合設(shè)計(jì)有幾個(gè)實(shí)操原則都是我用代價(jià)換來(lái)的第一聚合要盡量小。一個(gè)大聚合在并發(fā)修改時(shí)沖突概率高性能瓶頸明顯業(yè)務(wù)規(guī)則很容易堆成迷宮。不要貪心把所有能關(guān)聯(lián)的都裝進(jìn)一個(gè)聚合里。只需要問(wèn)一個(gè)問(wèn)題“這條業(yè)務(wù)規(guī)則被違反時(shí)最壞后果是什么一秒后修復(fù)可以嗎”如果可以就可以拆出來(lái)。第二聚合內(nèi)通過(guò)根實(shí)體訪問(wèn)內(nèi)部對(duì)象外部不能直接修改內(nèi)部對(duì)象。訂單聚合如果暴露了“直接修改第三行明細(xì)數(shù)量”的方法本質(zhì)上就是讓外部破壞聚合的不變量。正確做法是暴露“修改第幾行、新數(shù)量是多少”這樣的業(yè)務(wù)方法由聚合內(nèi)部判斷該行是否存在、數(shù)量是否合法再?zèng)Q定是否修改。第三聚合間的最終一致性要落在領(lǐng)域事件上。訂單取消后通知庫(kù)存釋放預(yù)占庫(kù)存這個(gè)操作不能放在一個(gè)本地事務(wù)里把庫(kù)存表和訂單表一起update正確姿勢(shì)是訂單聚合發(fā)布一個(gè)領(lǐng)域事件庫(kù)存上下文訂閱后自己處理。很多團(tuán)隊(duì)一開(kāi)始不習(xí)慣覺(jué)得事務(wù)跨了服務(wù)不保險(xiǎn)但行業(yè)標(biāo)準(zhǔn)做法就是通過(guò)可靠事件投遞機(jī)制比如事務(wù)發(fā)件箱模式來(lái)保證最終一致。第四與數(shù)據(jù)庫(kù)反問(wèn)這個(gè)聚合根對(duì)應(yīng)一張表嗎沒(méi)有這種必然關(guān)系。一個(gè)聚合可能對(duì)應(yīng)多張表也可能一個(gè)聚合的數(shù)據(jù)就對(duì)應(yīng)表里的一行。持久化模型和領(lǐng)域模型是不同的關(guān)注點(diǎn)ORM映射時(shí)要明確區(qū)分。2.3 領(lǐng)域事件讓模型轉(zhuǎn)身成為消息的來(lái)源領(lǐng)域事件在DDD里是重要但容易被誤用的概念。它不是通用消息隊(duì)列里的那種消息而是“過(guò)去已經(jīng)發(fā)生、對(duì)業(yè)務(wù)有意義的事情”在模型層面的表達(dá)。比如訂單已取消這就是一個(gè)領(lǐng)域事件它的名字用過(guò)去時(shí)態(tài)里面裝的是事件發(fā)生那一刻的快照數(shù)據(jù)訂單號(hào)、取消原因、取消時(shí)間、操作人。下游關(guān)心的是事件本身而不是去訂單表里查最新?tīng)顟B(tài)。最容易犯的錯(cuò)誤是把領(lǐng)域事件當(dāng)命令用。有人發(fā)布OrderCancelRequested這種事件打算讓下游執(zhí)行某個(gè)動(dòng)作這混淆了“事件”和“命令”的語(yǔ)義。事件表達(dá)的是已發(fā)生事實(shí)命令表達(dá)的是請(qǐng)求意圖。領(lǐng)域事件應(yīng)該貨真價(jià)實(shí)地記錄事實(shí)否則事件溯源和訂閱方調(diào)試時(shí)都會(huì)混亂。實(shí)操中我建議在應(yīng)用層的事務(wù)邊界內(nèi)發(fā)布領(lǐng)域事件發(fā)布方式采用事務(wù)發(fā)件箱模式把領(lǐng)域事件和業(yè)務(wù)數(shù)據(jù)變更放在同一個(gè)本地事務(wù)里先寫(xiě)業(yè)務(wù)表再寫(xiě)一條事件記錄到發(fā)件箱表然后由后臺(tái)任務(wù)或CDC變更數(shù)據(jù)捕獲機(jī)制把事件發(fā)布到消息中間件。這樣既能保證事件不丟又不要求把兩個(gè)不同服務(wù)的數(shù)據(jù)放在跨庫(kù)事務(wù)里。2.4 領(lǐng)域服務(wù)與貧血模型別把領(lǐng)域邏輯全部堆到應(yīng)用層企業(yè)應(yīng)用里最常見(jiàn)的壞味道就是貧血模型實(shí)體只有一堆getter和setter業(yè)務(wù)邏輯全部寫(xiě)在Service類里。這種代碼表面上分層清晰實(shí)際上把最重要的業(yè)務(wù)規(guī)則都散落在事務(wù)腳本里復(fù)用了實(shí)體也復(fù)用不了邏輯最后service類動(dòng)輒幾千行每一個(gè)新人來(lái)了都要花一周捋清楚。DDD要求把業(yè)務(wù)邏輯放入領(lǐng)域?qū)臃彩悄芊胚M(jìn)實(shí)體的邏輯就放入實(shí)體方法凡是涉及多個(gè)聚合協(xié)作的純業(yè)務(wù)邏輯放入領(lǐng)域服務(wù)應(yīng)用層只負(fù)責(zé)編排、事務(wù)邊界、權(quán)限控制、DTO轉(zhuǎn)換這些低價(jià)值工作。舉一個(gè)很常見(jiàn)的例子計(jì)算訂單總金額。很多團(tuán)隊(duì)把總金額簡(jiǎn)化成一個(gè)字段下單時(shí)在service里統(tǒng)一算好存進(jìn)表里。這在DDD里是很可疑的設(shè)計(jì)如果總金額是一個(gè)可以通過(guò)明細(xì)行金額和優(yōu)惠規(guī)則推導(dǎo)出來(lái)的值為什么不直接在聚合內(nèi)部提供一個(gè)業(yè)務(wù)方法來(lái)計(jì)算這樣當(dāng)優(yōu)惠規(guī)則變化時(shí)可以保證邏輯收斂在訂單聚合內(nèi)而不是散落在各個(gè)調(diào)用方。不過(guò)要提醒一點(diǎn)不要把領(lǐng)域服務(wù)濫用成新的上帝類。正確的領(lǐng)域服務(wù)應(yīng)該是粒度很小的、專注于“多個(gè)聚合協(xié)調(diào)產(chǎn)生一個(gè)結(jié)果”的純邏輯操作如果一個(gè)領(lǐng)域服務(wù)里做了十幾件事那多半是漏了什么模型概念應(yīng)該回頭重新審視模型。3. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 從業(yè)務(wù)流程出發(fā)做事件風(fēng)暴工作坊DDD落地第一步我不建議直接打開(kāi)IDE建工程更建議先組織一次事件風(fēng)暴工作坊。這個(gè)東西聽(tīng)起來(lái)門(mén)檻高操作起來(lái)就是一群人圍在一面大墻前用不同顏色的便簽紙分別記錄領(lǐng)域事件、命令、角色、聚合、外部系統(tǒng)然后一張張鋪開(kāi)排成時(shí)間線。我操盤(pán)過(guò)一個(gè)典型的模擬項(xiàng)目X某電商平臺(tái)重構(gòu)訂單核心系統(tǒng)。第一天工作坊只定了一個(gè)目標(biāo)梳理“從用戶點(diǎn)擊購(gòu)買(mǎi)到訂單關(guān)閉全生命周期”里究竟會(huì)發(fā)生哪些領(lǐng)域事件。便簽從“用戶提交訂單”開(kāi)始依次貼出“訂單已創(chuàng)建”“支付已發(fā)起”“支付已完成”“庫(kù)存已預(yù)占”“訂單已發(fā)貨”“訂單已簽收”“訂單已取消”等等。這一步最大的價(jià)值在于把分散在不同人腦子里的業(yè)務(wù)知識(shí)顯性化。從領(lǐng)域事件時(shí)間線里誰(shuí)發(fā)起、期望什么結(jié)果哪些操作是連貫的哪些需要跨領(lǐng)域協(xié)作都浮出水面。畫(huà)完時(shí)間線后再把命令和角色標(biāo)注上去一條清晰的業(yè)務(wù)流程就可靠得多。工作坊結(jié)束后的產(chǎn)出絕不是一面便利貼墻和幾張照片而是一份業(yè)務(wù)術(shù)語(yǔ)表。這個(gè)詞表必須精確定義每個(gè)業(yè)務(wù)動(dòng)作和對(duì)象的含義比如“訂單取消”在下單后未支付和發(fā)貨后客戶退貨這兩種場(chǎng)景下是不同的概念術(shù)語(yǔ)表里要區(qū)分為“系統(tǒng)取消”和“退貨單創(chuàng)建”。統(tǒng)一術(shù)語(yǔ)以后領(lǐng)域模型設(shè)計(jì)、代碼命名、PR描述、測(cè)試用例全都以術(shù)語(yǔ)表為準(zhǔn)避免各說(shuō)各話。3.2 識(shí)別限界上下文劃分服務(wù)與模塊的核心依據(jù)事件風(fēng)暴結(jié)束后下一步是把事件按業(yè)務(wù)歸屬分組形成限界上下文。分組時(shí)不要按技術(shù)模塊分比如不要出現(xiàn)“用戶模塊”“數(shù)據(jù)庫(kù)模塊”這種分組也不要按團(tuán)隊(duì)組織分要站在業(yè)務(wù)能力角度劃分。我習(xí)慣用三個(gè)強(qiáng)制問(wèn)題來(lái)篩每一個(gè)候選上下文這個(gè)上下文在解決誰(shuí)的什么問(wèn)題它使用哪些業(yè)務(wù)術(shù)語(yǔ)它產(chǎn)生的數(shù)據(jù)別的上下文需要用什么方式獲取在三問(wèn)過(guò)程中一個(gè)高頻爭(zhēng)論點(diǎn)是“用戶”。用戶這個(gè)概念在登錄認(rèn)證、個(gè)人中心、訂單履約、客服工單里都存在但每個(gè)上下文關(guān)心的用戶信息完全不同。認(rèn)證上下文里用戶是憑證持有者履約上下文里用戶是收貨人客服上下文里用戶是工單發(fā)起者。如果你試圖建一個(gè)統(tǒng)一用戶模型讓所有系統(tǒng)共享大概率又要做成一個(gè)巨型通用模塊。成熟的方案是有獨(dú)立的身份上下文負(fù)責(zé)憑證、個(gè)人資料等基礎(chǔ)數(shù)據(jù)其他上下文各自維護(hù)自己業(yè)務(wù)視圖下的用戶數(shù)據(jù)比如收貨地址、默認(rèn)發(fā)票信息這些數(shù)據(jù)不是每次去身份上下文拉一整套用戶大對(duì)象而是在自己的數(shù)據(jù)庫(kù)里維護(hù)本地視圖。這個(gè)邊界畫(huà)清楚了服務(wù)拆分就順理成章。3.3 從戰(zhàn)略到代碼一種可快速落地的工程目錄與編碼范式很多團(tuán)隊(duì)DDD落不了地的最后一公里是說(shuō)不清楚代碼到底應(yīng)該怎么擺放。我給一個(gè)我一直在用的工程目錄結(jié)構(gòu)這個(gè)結(jié)構(gòu)兼容Spring Boot和普通Java工程PHP、Go等語(yǔ)言可以按同樣思想套用interfaces用戶接口層放Controller、MQ消費(fèi)者、外部網(wǎng)關(guān)適配職責(zé)是協(xié)議轉(zhuǎn)換和參數(shù)校驗(yàn)。application應(yīng)用層放應(yīng)用服務(wù)編排用例管理事務(wù)邊界發(fā)布領(lǐng)域事件不做任何業(yè)務(wù)規(guī)則判斷。domain領(lǐng)域?qū)臃艑?shí)體、值對(duì)象、聚合根、領(lǐng)域服務(wù)、領(lǐng)域事件、倉(cāng)儲(chǔ)接口、領(lǐng)域異常。infrastructure基礎(chǔ)設(shè)施層放倉(cāng)儲(chǔ)實(shí)現(xiàn)、消息發(fā)送、外部HTTP調(diào)用、數(shù)據(jù)庫(kù)映射、緩存操作等。代碼層級(jí)約束要守住兩條鐵律依賴方向只能從外層指向內(nèi)層領(lǐng)域?qū)硬荒芤蕾嚾魏位A(chǔ)設(shè)施細(xì)節(jié)所以倉(cāng)儲(chǔ)接口定義在領(lǐng)域?qū)訉?shí)現(xiàn)放在基礎(chǔ)設(shè)施層。第二應(yīng)用層不能直接操作實(shí)體內(nèi)部狀態(tài)只能調(diào)用聚合根暴露的業(yè)務(wù)方法。寫(xiě)一個(gè)訂單取消的用例從Controller到基礎(chǔ)設(shè)施的完整鏈條應(yīng)該是這樣Controller接收取消請(qǐng)求轉(zhuǎn)成應(yīng)用服務(wù)的方法參數(shù)應(yīng)用服務(wù)先調(diào)用倉(cāng)儲(chǔ)從數(shù)據(jù)庫(kù)里把訂單聚合加載出來(lái)然后判斷當(dāng)前用戶有沒(méi)有取消權(quán)限——權(quán)限判斷屬于應(yīng)用層事務(wù)腳本不放進(jìn)領(lǐng)域?qū)印又{(diào)用訂單聚合的cancel方法修改狀態(tài)并發(fā)布區(qū)域事件最后調(diào)用倉(cāng)儲(chǔ)保存。保存動(dòng)作會(huì)在這個(gè)事務(wù)里同時(shí)寫(xiě)入訂單狀態(tài)、事件發(fā)件箱記錄。實(shí)操中還有個(gè)細(xì)節(jié)值得注意加載聚合時(shí)一定要帶上做業(yè)務(wù)判斷所需的所有數(shù)據(jù)。我見(jiàn)過(guò)有人圖省事先load訂單頭信息判斷完?duì)顟B(tài)要改明細(xì)時(shí)發(fā)現(xiàn)明細(xì)沒(méi)加載又去調(diào)一次倉(cāng)儲(chǔ)結(jié)果業(yè)務(wù)方法本身被拆得七零八落。正確的倉(cāng)儲(chǔ)設(shè)計(jì)應(yīng)該提供清晰明確的加載接口比如findById(id)返回完整聚合如果因?yàn)殚_(kāi)銷問(wèn)題不需要全加載再設(shè)計(jì)專門(mén)的輕量查詢路徑那也應(yīng)該是顯示接口比如findSummaryById而不是讓調(diào)用方在同一個(gè)聚合對(duì)象上做流式懶加載。3.4 防腐層與開(kāi)放主機(jī)服務(wù)系統(tǒng)間協(xié)作的護(hù)城河限界上下文之間協(xié)作不是無(wú)腦HTTP調(diào)用。每個(gè)下游上下文對(duì)上游數(shù)據(jù)都有自己的理解和加工方式所以上下文之間按邊界類型選協(xié)作模式。最常用的是防腐層Anticorruption Layer。這個(gè)詞聽(tīng)著抽象其實(shí)就是一個(gè)翻譯層把上游上下文傳過(guò)來(lái)的模型翻譯成當(dāng)前上下文能理解的模型。比如外部供應(yīng)商系統(tǒng)管他們的數(shù)據(jù)叫“項(xiàng)目編號(hào)”我們內(nèi)部實(shí)際叫“任務(wù)ID”兩個(gè)系統(tǒng)對(duì)接時(shí)防腐層負(fù)責(zé)把“項(xiàng)目編號(hào)”翻譯成“任務(wù)ID”后續(xù)領(lǐng)域?qū)铀羞壿嬛徽J(rèn)識(shí)“任務(wù)ID”不認(rèn)識(shí)“項(xiàng)目編號(hào)”。這樣做最大的好處是外部系統(tǒng)的模型變化不會(huì)污染內(nèi)部模型。上游供應(yīng)商改了字段語(yǔ)義我們只需修改防腐層不需要改動(dòng)領(lǐng)域模型和業(yè)務(wù)代碼。所有第三方API客戶端、消息消費(fèi)者、讀模型轉(zhuǎn)換都應(yīng)該住在防腐層內(nèi)這個(gè)層很薄但它是一道關(guān)鍵性屏障。對(duì)外提供服務(wù)時(shí)推薦用開(kāi)放主機(jī)服務(wù)Open Host Service模式為每種外部消費(fèi)者提供專用接口。比如我們?yōu)锳pp端、小程序端、內(nèi)部運(yùn)維后臺(tái)分別提供不同的DTO和接口而不是一個(gè)萬(wàn)能DTO應(yīng)付所有端這樣任一端的展示需求變化不會(huì)影響本上下文的領(lǐng)域模型。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 聚合邊界畫(huà)錯(cuò)的典型癥狀與修復(fù)策略聚合邊界是DDD項(xiàng)目里返工最多的地方。畫(huà)得太粗一個(gè)大聚合動(dòng)不動(dòng)幾千行并發(fā)沖突、性能瓶頸、修改范圍全部爆炸畫(huà)得太細(xì)一堆小聚合之間互相調(diào)倉(cāng)儲(chǔ)拿數(shù)據(jù)一致性一塌糊涂業(yè)務(wù)規(guī)則被拆成片段到處飛。歸結(jié)起來(lái)畫(huà)得不對(duì)的典型癥狀有這么幾個(gè)領(lǐng)域方法里頻繁訪問(wèn)其他聚合的數(shù)據(jù)一個(gè)用例要連續(xù)加載多個(gè)聚合做判斷表結(jié)構(gòu)設(shè)計(jì)先于聚合設(shè)計(jì)。診斷時(shí)我會(huì)重新逐個(gè)梳理業(yè)務(wù)不變量哪些業(yè)務(wù)規(guī)則一旦被打破系統(tǒng)就必須拒絕操作或立即補(bǔ)償這些規(guī)則覆蓋的對(duì)象就必須在一個(gè)聚合內(nèi)。分享一個(gè)具體調(diào)整案例。模擬項(xiàng)目X里有一個(gè)“優(yōu)惠券”模型最初設(shè)計(jì)是優(yōu)惠券聚合綁定用戶每次下單時(shí)應(yīng)用層同時(shí)加載訂單聚合和優(yōu)惠券聚合判斷優(yōu)惠券是否屬于該用戶、是否過(guò)期然后扣減優(yōu)惠券使用次數(shù)。問(wèn)題是這種跨聚合校驗(yàn)導(dǎo)致兩個(gè)聚合處于同一個(gè)強(qiáng)一致事務(wù)里但優(yōu)惠券CEO認(rèn)為“使用次數(shù)更新延遲一秒”完全沒(méi)問(wèn)題。重構(gòu)后下單時(shí)只校驗(yàn)優(yōu)惠券狀態(tài)快照訂單聚合自行判定總額與優(yōu)惠分?jǐn)們?yōu)惠券核銷通過(guò)領(lǐng)域事件異步處理。兩個(gè)聚合徹底分離事務(wù)范圍縮小并發(fā)提升業(yè)務(wù)上沒(méi)有任何抱怨。這件事給我留下很深的印象不少一致性約束其實(shí)是可以放寬的聚合設(shè)計(jì)時(shí)多追問(wèn)一句“真的必須強(qiáng)一致嗎”往往能得到更好的邊界。4.2 分布式事務(wù)悖論別再用全局鎖換虛假的“一致”把DDD落地成微服務(wù)之后一個(gè)繞不開(kāi)的問(wèn)題是跨上下文的數(shù)據(jù)一致性。不少團(tuán)隊(duì)在重構(gòu)前是一套單體、一個(gè)數(shù)據(jù)庫(kù)所有表可以隨意join現(xiàn)在拆成多個(gè)服務(wù)、多個(gè)庫(kù)自然會(huì)遇到分布式事務(wù)問(wèn)題。很多人第一反應(yīng)是引入分布式事務(wù)框架做全局事務(wù)。但我要潑一盆冷水分布式事務(wù)會(huì)把系統(tǒng)性能拖垮還會(huì)把服務(wù)邊界重新耦合在一起違背了拆分服務(wù)的初衷。微服務(wù)架構(gòu)下跨上下文一致性的正確姿態(tài)是主動(dòng)擁抱最終一致性。標(biāo)準(zhǔn)做法就是前面提到的可靠事件投遞領(lǐng)域?qū)影l(fā)出事件與業(yè)務(wù)數(shù)據(jù)寫(xiě)進(jìn)同一個(gè)本地事務(wù)發(fā)件箱表然后由發(fā)布器掃描發(fā)件箱推送到消息中間件下游消費(fèi)端自己保證冪等。訂單服務(wù)和庫(kù)存服務(wù)各執(zhí)一份數(shù)據(jù)通過(guò)事件流對(duì)賬補(bǔ)償而不是靠一個(gè)全局事務(wù)鎖死所有庫(kù)。這套做法我第一次落地時(shí)業(yè)務(wù)方非常抵觸覺(jué)得數(shù)據(jù)短時(shí)間不一致無(wú)法接受。后來(lái)我寫(xiě)了一個(gè)對(duì)賬腳本每分鐘檢測(cè)兩邊數(shù)據(jù)差異差異超過(guò)閾值自動(dòng)告警并觸發(fā)補(bǔ)償。上線運(yùn)行兩個(gè)月實(shí)際數(shù)據(jù)差異率極低僅有的差異也都自動(dòng)消解。事實(shí)證明在人為設(shè)定的一致性和運(yùn)維側(cè)的對(duì)賬補(bǔ)償機(jī)制配合下大多數(shù)業(yè)務(wù)場(chǎng)景都接受最終一致性。4.3 領(lǐng)域模型還是數(shù)據(jù)模型ORM映射的認(rèn)知誤區(qū)用ORM實(shí)現(xiàn)DDD持久化時(shí)最常見(jiàn)的坑是試圖讓數(shù)據(jù)庫(kù)表結(jié)構(gòu)直接對(duì)應(yīng)領(lǐng)域?qū)ο蠼Y(jié)構(gòu)。這種思路本質(zhì)上是拿數(shù)據(jù)模型冒充領(lǐng)域模型結(jié)果要么是領(lǐng)域模型為了迎合表結(jié)構(gòu)而失去業(yè)務(wù)含義要么是表結(jié)構(gòu)被領(lǐng)域模型的奇形怪狀搞得不倫不類。正確認(rèn)知是領(lǐng)域模型是運(yùn)行時(shí)的內(nèi)存態(tài)表結(jié)構(gòu)是持久化形態(tài)兩者之間是一種規(guī)格化的存儲(chǔ)表示。ORM實(shí)現(xiàn)工具只是把內(nèi)存態(tài)翻譯成持久態(tài)的工具翻譯過(guò)程需要精心設(shè)計(jì)。值對(duì)象可以用一張單獨(dú)的從表存多條記錄或者用JSON列存儲(chǔ)甚至用逗號(hào)分隔字符串只要能可靠往返即可。這里要提醒一個(gè)很實(shí)際的坑不要為了追求“純粹領(lǐng)域模型”而把持久化映射搞得極其復(fù)雜比如大量使用ORM高級(jí)特性來(lái)做多態(tài)映射一旦升級(jí)版本或者遇到冷門(mén)數(shù)據(jù)庫(kù)方言可能會(huì)在詭異的地方爆炸。我的經(jīng)驗(yàn)是領(lǐng)域模型保持充分表達(dá)力但持久化盡可能簡(jiǎn)單常規(guī)一個(gè)實(shí)體一張主表值對(duì)象用JSON或單列存儲(chǔ)都行優(yōu)先考慮維護(hù)簡(jiǎn)單。4.4 術(shù)語(yǔ)表是跨團(tuán)隊(duì)協(xié)作的粘合劑不是文檔擺設(shè)DDD項(xiàng)目想要運(yùn)轉(zhuǎn)順暢必須讓業(yè)務(wù)人員、產(chǎn)品經(jīng)理、開(kāi)發(fā)、測(cè)試說(shuō)的是同一種語(yǔ)言這就是通用語(yǔ)言Ubiquitous Language的作用。通用語(yǔ)言的核心不是高深的建模技巧而是一份被所有人共同遵守的業(yè)務(wù)術(shù)語(yǔ)表。術(shù)語(yǔ)表不是一次性產(chǎn)出它是一個(gè)持續(xù)演進(jìn)的過(guò)程。每發(fā)現(xiàn)一個(gè)新的概念、每個(gè)命名分歧、每個(gè)“這個(gè)名字別處也在用”的苗頭都及時(shí)更新進(jìn)表里同時(shí)指定一名業(yè)務(wù)代表當(dāng)術(shù)語(yǔ)表的最終仲裁者誰(shuí)說(shuō)了都不算業(yè)務(wù)代表點(diǎn)頭才算。術(shù)語(yǔ)表怎么影響代碼我在項(xiàng)目里定了一個(gè)機(jī)制所有類名、方法名、字段名都優(yōu)先從術(shù)語(yǔ)表里找詞術(shù)語(yǔ)表里沒(méi)有的詞不允許出現(xiàn)在代碼注釋和PR說(shuō)明中。這么做看起來(lái)有點(diǎn)一刀切實(shí)際效果很直接代碼的可讀性、業(yè)務(wù)人員參與評(píng)審的意愿、新員工上手速度都明顯提升沒(méi)有術(shù)語(yǔ)表的時(shí)候大家討論問(wèn)題能爭(zhēng)十分鐘原因只是雙方說(shuō)的“訂單狀態(tài)”其實(shí)指的不是同一個(gè)東西。5. 落地的工程化支撐5.1 倉(cāng)儲(chǔ)模式的價(jià)值在哪里以及什么時(shí)候不該用倉(cāng)儲(chǔ)Repository模式是DDD的重要組成部分它存在的意義不是“把數(shù)據(jù)庫(kù)訪問(wèn)封裝一下”這么淺層而是為領(lǐng)域模型提供一個(gè)基于集合概念的存儲(chǔ)接口。領(lǐng)域?qū)又恍枰f(shuō)“把訂單聚合保存起來(lái)”或“根據(jù)訂單號(hào)取回訂單聚合”不需要知道底層是關(guān)系型數(shù)據(jù)庫(kù)、NoSQL、還是文件存儲(chǔ)。在實(shí)操中倉(cāng)儲(chǔ)接口放在領(lǐng)域?qū)訉?shí)現(xiàn)放在基礎(chǔ)設(shè)施層這是依賴倒置的體現(xiàn)。很多人用倉(cāng)儲(chǔ)模式時(shí)只是改了個(gè)名字實(shí)際還是把DAO那套findBy...、updateBy...接口原樣鋪了一遍這就是典型的披著DDD外衣的基于數(shù)據(jù)庫(kù)操作開(kāi)發(fā)沒(méi)有為領(lǐng)域?qū)犹峁┤魏斡幸饬x的能力。怎樣的倉(cāng)儲(chǔ)接口才算合格接口命名應(yīng)該面向業(yè)務(wù)語(yǔ)言比如findPendingOrders查找待支付訂單、save(OrderAggregate)、removeById方法參數(shù)和返回值應(yīng)該只出現(xiàn)領(lǐng)域類型而不是DTO或QueryObject。實(shí)現(xiàn)倉(cāng)儲(chǔ)時(shí)內(nèi)部邏輯是把聚合拆成持久化對(duì)象、再做反向拼裝拼裝邏輯是ORM關(guān)注的重點(diǎn)。不過(guò)倉(cāng)儲(chǔ)不是萬(wàn)能解藥。對(duì)于純粹的報(bào)表查詢、搜索列表、統(tǒng)計(jì)面板不需要走倉(cāng)儲(chǔ)去加載聚合直接使用查詢通道做讀模型投影會(huì)更合適。DDD的CQRS思想就是默認(rèn)寫(xiě)操作走聚合與倉(cāng)儲(chǔ)讀操作可以走輕量查詢、甚至直接寫(xiě)SQL避免把所有獲取數(shù)據(jù)的路徑都?jí)航o聚合裝載器。5.2 事件溯源要不要上DDD的進(jìn)階選項(xiàng)聊DDD很難繞開(kāi)事件溯源Event Sourcing——一種不存對(duì)象當(dāng)前狀態(tài)、只存狀態(tài)變更事件序列的持久化方式。這個(gè)概念很吸引人似乎只要用了事件溯源業(yè)務(wù)系統(tǒng)的追溯性、審計(jì)性、可擴(kuò)展性全都解決了。但我對(duì)技術(shù)選型的建議一直很保守只有被明確需求逼到非上不可時(shí)才用事件溯源。比如對(duì)審計(jì)要求極其嚴(yán)格的資金流水系統(tǒng)、需要完整回放歷史的合規(guī)系統(tǒng)事件溯源的價(jià)值是壓倒性的而像普通的內(nèi)容管理、報(bào)表分析類系統(tǒng)引入事件溯源反而增加復(fù)雜度事件表膨脹、狀態(tài)重建耗時(shí)、事件結(jié)構(gòu)演進(jìn)版本遷移這些都是實(shí)實(shí)在在的額外負(fù)擔(dān)。還有一種折中方案是只對(duì)核心高價(jià)值聚合啟用事件溯源其余聚合走傳統(tǒng)狀態(tài)持久化。這種局部事件溯源策略能在有限成本內(nèi)獲取最大好處我比較推薦有這個(gè)訴求的團(tuán)隊(duì)考慮。5.3 工程上讓DDD可落地的幾個(gè)實(shí)踐機(jī)制DDD要在一個(gè)團(tuán)隊(duì)里落地光有理論不行還要有配套的強(qiáng)制機(jī)制。我在項(xiàng)目里一般會(huì)建立三個(gè)機(jī)制缺一不可。第一是模型評(píng)審機(jī)制。每周固定時(shí)間業(yè)務(wù)代表、開(kāi)發(fā)、測(cè)試坐下來(lái)對(duì)著最近更新的領(lǐng)域模型過(guò)一遍所有新增實(shí)體、方法、事件都從頭講一遍業(yè)務(wù)故事。這種評(píng)審在早期極其痛苦因?yàn)闃I(yè)務(wù)和開(kāi)發(fā)存在“雞同鴨講”堅(jiān)持幾個(gè)月后價(jià)值會(huì)越來(lái)越大模型偏差在實(shí)現(xiàn)前就被發(fā)現(xiàn)節(jié)省大量返工成本。第二是代碼邊界守護(hù)機(jī)制。這道防線可以靠架構(gòu)測(cè)試組件或代碼審查紀(jì)律來(lái)實(shí)現(xiàn)。比如在Java項(xiàng)目里用ArchUnit寫(xiě)測(cè)試斷言領(lǐng)域?qū)硬荒躨mport基礎(chǔ)設(shè)施包、應(yīng)用層不能出現(xiàn)具體的HTTP客戶端和Mapper。這些測(cè)試加進(jìn)流水線任何越界依賴在CI階段就掛掉比評(píng)審時(shí)人肉盯更可靠。第三是業(yè)務(wù)術(shù)語(yǔ)治理機(jī)制。術(shù)語(yǔ)表不是寫(xiě)文檔要落到代碼里當(dāng)開(kāi)發(fā)把一個(gè)新類名寫(xiě)進(jìn)代碼前先在術(shù)語(yǔ)表里檢索一下沒(méi)有就提請(qǐng)新增。對(duì)已經(jīng)建立良好的上下文還會(huì)用代碼生成或骨架模板固化通用語(yǔ)言到命名規(guī)范中。6. 關(guān)于DDD的一些經(jīng)驗(yàn)沉淀老實(shí)說(shuō)我見(jiàn)過(guò)不少團(tuán)隊(duì)把DDD當(dāng)銀彈以為上了DDD微服務(wù)就順了、代碼就優(yōu)雅了、需求變更就簡(jiǎn)單了。真正實(shí)踐過(guò)才發(fā)現(xiàn)DDD是放大器而不是修復(fù)器如果需求本來(lái)就一團(tuán)亂麻、業(yè)務(wù)方無(wú)法清晰描述流程、團(tuán)隊(duì)沒(méi)有基礎(chǔ)的分層和質(zhì)量意識(shí)DDD不會(huì)自動(dòng)把這些變好只會(huì)把已有的混亂放大到更容易爆炸的規(guī)模。我個(gè)人的體感是DDD最值得投入的時(shí)間在“建模期”而不是“編碼期”。很多團(tuán)隊(duì)在代碼寫(xiě)到一半時(shí)才發(fā)現(xiàn)邊界定錯(cuò)了然后就陷入“要不要重來(lái)”的痛苦抉擇。所以從一開(kāi)始就值得用事件風(fēng)暴工作坊把核心流程徹底理清把術(shù)語(yǔ)表做扎實(shí)這些事糙但必須別跳。還有一點(diǎn)經(jīng)驗(yàn)是DDD不要追求一次到位可以像切蛋糕一樣分階段落地。第一個(gè)迭代只選一個(gè)核心業(yè)務(wù)鏈路做DDD改造其他鏈路繼續(xù)走傳統(tǒng)分層先讓團(tuán)隊(duì)感受到DDD帶來(lái)的模型清晰感再逐步擴(kuò)大范圍。這種方式能降低風(fēng)險(xiǎn)也能讓觀望者看到實(shí)實(shí)在在的增量收益比一開(kāi)始就全量重構(gòu)要穩(wěn)妥得多。如果要給一條最有價(jià)值的建議我會(huì)說(shuō)先找到一個(gè)懂業(yè)務(wù)的業(yè)務(wù)人員讓他愿意陪你做事件風(fēng)暴愿意和你逐詞逐句摳術(shù)語(yǔ)表。有了這個(gè)人在DDD已經(jīng)成功一半沒(méi)有這個(gè)人什么高超的戰(zhàn)術(shù)模式都是沙上建塔。技術(shù)永遠(yuǎn)有解業(yè)務(wù)模型亂了解數(shù)學(xué)不出來(lái)。