簡(jiǎn)介 

DDD是一套方法論，一套思想。種類繁多的元模型和名詞概念。其本質(zhì)都是指導(dǎo)思想對(duì)應(yīng)的解決方案“之一”，初學(xué)者容易被表象所困。應(yīng)始終清醒保持認(rèn)知“DDD各種元模型都是為解決實(shí)際開(kāi)發(fā)中某類問(wèn)題而起”。在接觸各類元模型時(shí)應(yīng)結(jié)合自身業(yè)務(wù)面臨問(wèn)題來(lái)求證，這樣有助于避免被概念表象所困，回歸解決問(wèn)題的本質(zhì)。

 背景 

數(shù)據(jù)架構(gòu)團(tuán)隊(duì)從18年開(kāi)始，受業(yè)務(wù)需求驅(qū)動(dòng)開(kāi)發(fā)電話機(jī)器人，轉(zhuǎn)眼已近5年。目前，在該平臺(tái)下已搭建100+不同類型機(jī)器人，為公司經(jīng)銷商、二手車、主機(jī)廠、金融等多個(gè)BU業(yè)務(wù)提供外呼能力，日外呼量幾十萬(wàn)通。電話機(jī)器人項(xiàng)目已初具規(guī)模，但過(guò)程中也遇到不少挑戰(zhàn)。為了應(yīng)對(duì)這些挑戰(zhàn)，我們團(tuán)隊(duì)最終采用DDD思想進(jìn)行重構(gòu)和開(kāi)發(fā)。

在應(yīng)用DDD的過(guò)程中，數(shù)據(jù)架構(gòu)團(tuán)隊(duì)落地了一些自己的開(kāi)發(fā)規(guī)范。這里就把一些經(jīng)驗(yàn)和想法分享給大家，希望能起到拋磚引玉作用。這里解釋一下，篇幅中很多元模型沒(méi)有展開(kāi)講，也沒(méi)有給出具體案例。一是考慮到篇幅長(zhǎng)度問(wèn)題。二是理解了DDD思想，結(jié)合各自業(yè)務(wù)來(lái)實(shí)現(xiàn)就好了，給出在我業(yè)務(wù)的例子意義并不大。此外這類案例很容易找的到。同時(shí)，覺(jué)得給出我們團(tuán)隊(duì)遇到的問(wèn)題、解決方案，落地過(guò)程和我們形成的開(kāi)發(fā)規(guī)范對(duì)大家來(lái)說(shuō)更有價(jià)值。對(duì)DDD感興趣，想了解更多或?qū)Ρ疚挠幸蓡?wèn)的同學(xué)，歡迎找我交流討論。

下面，我從這幾個(gè)部分來(lái)進(jìn)行分享：機(jī)器人項(xiàng)目中遇到的挑戰(zhàn)、為什么是DDD、DDD落地步驟、對(duì)團(tuán)隊(duì)帶來(lái)的提升、理論到實(shí)戰(zhàn)遇到的沖突以及未來(lái)在DDD應(yīng)用方面的改進(jìn)和總結(jié)。

 1.遇到的挑戰(zhàn) 

挑戰(zhàn)一：業(yè)務(wù)邏輯復(fù)雜度高。隨著各類業(yè)務(wù)的接入，為應(yīng)對(duì)不同場(chǎng)景下的特定業(yè)務(wù)，不斷追加新邏輯。

如：流程中的意圖識(shí)別邏輯。

意圖識(shí)別需要依賴AI的多個(gè)模型識(shí)別，多個(gè)模型識(shí)別出來(lái)的意圖有可能是沖突的，需要對(duì)沖突的意圖配置規(guī)則做取舍。同時(shí)，對(duì)一些冷啟動(dòng)或者緊急優(yōu)化的場(chǎng)景，需要支持通過(guò)配置規(guī)則實(shí)時(shí)生效的方式來(lái)意圖識(shí)別。并且在規(guī)則的意圖識(shí)別中需要支持匹配詞槽。詞槽的類型又有多種，從優(yōu)先級(jí)上區(qū)分有場(chǎng)景的全局詞槽、流程上的詞槽。從數(shù)據(jù)識(shí)別來(lái)源上區(qū)分，可以分為AI識(shí)別出來(lái)的，詞典規(guī)則匹配出來(lái)的，還可能是業(yè)務(wù)方傳遞進(jìn)來(lái)的。業(yè)務(wù)開(kāi)展一段時(shí)間后，不同類型的詞槽又增加不同屬性，如車系的詞槽有本品、經(jīng)營(yíng)范圍、非經(jīng)營(yíng)等等；

 挑戰(zhàn)二：代碼架構(gòu)結(jié)構(gòu)不清晰。隨著業(yè)務(wù)需求功能的追加，伴隨著代碼規(guī)模增大。加之邏輯復(fù)雜和團(tuán)隊(duì)開(kāi)發(fā)人員代碼迥異，逐漸導(dǎo)致各種邏輯邊界變得混亂。

如：我們通常的開(kāi)發(fā)方式，按功能模塊拆解，業(yè)務(wù)流程串聯(lián)協(xié)調(diào)各個(gè)模塊，共同完成業(yè)務(wù)需求。但是處理這類業(yè)務(wù)復(fù)雜的邏輯，這種方案設(shè)計(jì)有很大的弊端，模塊邊界很容易被穿透。

各模塊關(guān)系相互調(diào)用，原本作為模塊的隔離設(shè)計(jì)，實(shí)際在實(shí)現(xiàn)過(guò)程被完完全全的打破了。使原本理想中垂直拆分的模塊，變成網(wǎng)狀的結(jié)構(gòu)。

模塊負(fù)責(zé)人中間環(huán)節(jié)開(kāi)發(fā)出來(lái)的的屬性或方法，被外部其它模塊外依賴導(dǎo)致功能發(fā)散出去。導(dǎo)致后期需求變動(dòng)時(shí)風(fēng)險(xiǎn)增加，又或是發(fā)現(xiàn)被依賴了原本可以隨意更改的方法不能變動(dòng)，不得不增加額外邏輯代碼來(lái)實(shí)現(xiàn)。造成了本就復(fù)雜的代碼更加復(fù)雜。

對(duì)業(yè)務(wù)需求拆解不合理，需求功能在實(shí)現(xiàn)時(shí)就近開(kāi)發(fā)，未嚴(yán)格按照模塊拆解，缺少統(tǒng)一思想作為指導(dǎo)。

挑戰(zhàn)三：產(chǎn)品需求多，難以辨別是否有真實(shí)價(jià)值。

挑戰(zhàn)四：邏輯變化快，不少需求導(dǎo)致需要代碼邏輯重新設(shè)計(jì)。

挑戰(zhàn)五：業(yè)務(wù)多，各業(yè)務(wù)表述不一致，溝通成本高。

垂直邊界被打破，代碼復(fù)雜度增加，加上業(yè)務(wù)流程頻繁調(diào)整。這些多重維度相互疊加，使得開(kāi)發(fā)和維護(hù)難度指數(shù)增加。電話機(jī)器人這個(gè)一級(jí)應(yīng)用系統(tǒng)的穩(wěn)定性難以保障。即便技術(shù)同學(xué)都是資深的工程師，已經(jīng)按照所能理解的微服務(wù)思想設(shè)計(jì)、按照模塊拆解項(xiàng)目，即便代碼邏輯中已經(jīng)也引用不少設(shè)計(jì)模式來(lái)構(gòu)建與擴(kuò)展，即便已經(jīng)是接入了公司各個(gè)平臺(tái)質(zhì)量工具、寫了不少單元測(cè)試。但是在項(xiàng)目新需求迭代時(shí)，依舊出現(xiàn)不少“驚喜”，使整個(gè)團(tuán)隊(duì)很頭疼。

2.為什么是DDD

為什么是DDD？每天那么多技術(shù)棧，那么多思想，為什么就是DDD來(lái)應(yīng)對(duì)呢？首先DDD修飾的很好“軟件核心復(fù)雜性應(yīng)對(duì)之道”，使得不少人想一探究竟。所以來(lái)看看DDD是怎么來(lái)解決項(xiàng)目中遇到的挑戰(zhàn)。

首先，我們來(lái)看看DDD對(duì)復(fù)雜度的歸類，弄明白DDD要應(yīng)對(duì)的復(fù)雜度是否是我面臨的挑戰(zhàn)。DDD相關(guān)資料中，從理解能力和預(yù)測(cè)能力兩個(gè)維度來(lái)探索剖析復(fù)雜度的成因。

理解能力(就是軟件系統(tǒng)對(duì)開(kāi)發(fā)人員來(lái)說(shuō)復(fù)雜難以理解)：

第一規(guī)模：影響理解能力的第一要素。幾百上千萬(wàn)行的代碼，各需求點(diǎn)的關(guān)系相互影響。修改一處就會(huì)牽一發(fā)動(dòng)全身。

第二結(jié)構(gòu)：不合理甚至混亂的結(jié)構(gòu)，導(dǎo)致開(kāi)發(fā)人員對(duì)功能難以維護(hù)。

預(yù)測(cè)能力(就是業(yè)務(wù)的發(fā)展難以預(yù)測(cè))：

當(dāng)需求變化時(shí)，難以預(yù)測(cè)軟件實(shí)現(xiàn)的走向，會(huì)出現(xiàn)過(guò)度設(shè)計(jì)和設(shè)計(jì)不足問(wèn)題。過(guò)度設(shè)計(jì)，預(yù)留了很多接口，構(gòu)造了很多模式增加了代碼的實(shí)現(xiàn)復(fù)雜度，但后來(lái)發(fā)現(xiàn)用不到。設(shè)計(jì)不足，需求的實(shí)現(xiàn)沒(méi)考慮到后期的發(fā)展，當(dāng)變化來(lái)臨時(shí)需要推翻現(xiàn)有設(shè)計(jì)重新開(kāi)發(fā)，被產(chǎn)品抱怨設(shè)計(jì)能力差。

DDD對(duì)復(fù)雜度的成因歸結(jié)為：規(guī)模、結(jié)構(gòu)、變化；規(guī)模和結(jié)構(gòu)制造了理解能力障礙，變化制造了預(yù)測(cè)能力障礙，兩者相加形成了復(fù)雜度問(wèn)題。

 其次，DDD并不僅僅是對(duì)代碼設(shè)計(jì)階段的理論，而是還包含從需求分析、架構(gòu)映射和建模及實(shí)現(xiàn)的全流程設(shè)計(jì)指導(dǎo)。

需求分析階段，通過(guò)相關(guān)指導(dǎo)思想提前準(zhǔn)確獲知業(yè)務(wù)價(jià)值，捕獲未來(lái)變化方向。架構(gòu)映射階段，給出從需求到架構(gòu)過(guò)程的指導(dǎo)思想，增加了設(shè)計(jì)權(quán)重和規(guī)范。通過(guò)子領(lǐng)域拆分、系統(tǒng)分層和限界上下文業(yè)務(wù)歸類，給出指導(dǎo)規(guī)范，保障了系統(tǒng)架構(gòu)的清晰，并且降低系統(tǒng)復(fù)雜度。建模及實(shí)現(xiàn)階段，給出來(lái)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)相關(guān)元模型，使各部分職能分工明確，快速響應(yīng)業(yè)務(wù)需求和未來(lái)功能變化。

再次，來(lái)看DDD給出的指導(dǎo)思想：

規(guī)模問(wèn)題：拆邊界。以子領(lǐng)域、限界上下文對(duì)拆解分治。

針對(duì)分治思想，DDD給出兩個(gè)重要的設(shè)計(jì)元模型：限界上下文和上下文映射。

結(jié)構(gòu)問(wèn)題：分層架構(gòu)+限界隔離。

分層起到了隔離業(yè)務(wù)邏輯和技術(shù)實(shí)現(xiàn)復(fù)雜度問(wèn)題。DDD引入的分層架構(gòu)，將業(yè)務(wù)邏輯封裝到領(lǐng)域?qū)?，支撐業(yè)務(wù)邏輯的技術(shù)實(shí)現(xiàn)放到基礎(chǔ)設(shè)施層。在領(lǐng)域?qū)又系膽?yīng)用層封裝應(yīng)用服務(wù)，粘合二者進(jìn)行協(xié)作。

變化問(wèn)題：主動(dòng)設(shè)計(jì)變化。

變化無(wú)法控制，只能擁抱變化。需求分析階段運(yùn)用5W思維識(shí)別變化規(guī)律，把控業(yè)務(wù)變化。DDD通過(guò)模型驅(qū)動(dòng)設(shè)計(jì)元模型對(duì)限界上下文進(jìn)行領(lǐng)域建模，形成結(jié)合分析、設(shè)計(jì)和實(shí)現(xiàn)一體的領(lǐng)域模型。

最后，來(lái)看DDD給出的解決方案。其引入了一套提煉為模式的設(shè)計(jì)元模型，對(duì)業(yè)務(wù)軟件做到了對(duì)規(guī)模的控制、結(jié)構(gòu)的拆分以及變化的主動(dòng)響應(yīng)。

 簡(jiǎn)單介紹下這張圖，整體分為兩個(gè)大部分。第一部分是下面虛線圈出來(lái)的部分，不涉及具體技術(shù)實(shí)現(xiàn)。在需求分析階段進(jìn)行的，應(yīng)對(duì)問(wèn)題空間的一些元模型方案。另外部分，在第一部分的基礎(chǔ)上，做具體系統(tǒng)架構(gòu)分層、對(duì)象抽離聚合、服務(wù)拆解環(huán)節(jié)，這個(gè)階段做對(duì)應(yīng)的設(shè)計(jì)落地。

我的理解是這樣，這套設(shè)計(jì)元模型給出了從需求分析、設(shè)計(jì)和實(shí)現(xiàn)一體整套解決方案。需求分析階段的系統(tǒng)拆解(對(duì)應(yīng)圖中子領(lǐng)域元模型)。再拆到更新粒度的限界上下文。并給出各限界的協(xié)同關(guān)系方案（對(duì)應(yīng)圖中上下文映射元模型）。設(shè)計(jì)實(shí)現(xiàn)階段給出模型驅(qū)動(dòng)設(shè)計(jì)的設(shè)計(jì)元方案,通過(guò)系統(tǒng)的分層架構(gòu)、領(lǐng)域服務(wù)、聚合等粒度的設(shè)計(jì)。給出一套完善的、有理論支撐的、可落地有標(biāo)準(zhǔn)的解決方案。

上述DDD對(duì)問(wèn)題復(fù)雜度的剖析定位，完全就是電話機(jī)器人系統(tǒng)中的痛點(diǎn)。給出的解決方案，也完美解決業(yè)務(wù)面臨的各類挑戰(zhàn)。認(rèn)識(shí)到其價(jià)值后，團(tuán)隊(duì)很快達(dá)成共識(shí)在后續(xù)的項(xiàng)目中進(jìn)行落地。

3. DDD落地步驟 

元模型細(xì)節(jié)、業(yè)務(wù)限界的拆解不展開(kāi)講了，直接給出我們團(tuán)隊(duì)實(shí)戰(zhàn)中的步驟和產(chǎn)物。

3.1第一步預(yù)研階段

這部分我們的經(jīng)驗(yàn)是團(tuán)隊(duì)中有人充當(dāng)先行者，先花費(fèi)精力做深入學(xué)習(xí)DDD相關(guān)理念，然后同步到整個(gè)團(tuán)隊(duì)。就我們團(tuán)隊(duì)來(lái)講，調(diào)研階段時(shí)間比較零碎不好評(píng)估用時(shí)多久，團(tuán)隊(duì)科普階段前后4次用時(shí)8小時(shí)。之后，團(tuán)隊(duì)內(nèi)同學(xué)在有概念指導(dǎo)的基礎(chǔ)上，已具備快速深入學(xué)習(xí)能力。并組織團(tuán)隊(duì)成內(nèi)相互探討印證理解。

3.2第二步引入指導(dǎo)思想和落地規(guī)范

 3.2.1 需求分析階段引入5W模型理論支撐，有助辨識(shí)出真實(shí)需求，主動(dòng)把控變化方向和排除無(wú)意義需求。

這部分就是5W理論作為跟產(chǎn)品分析需求的理論的支撐，非常有助于識(shí)別出真實(shí)的需求，更好的分析出業(yè)務(wù)的發(fā)展方向。也能從源頭上縮減無(wú)效需求，直接上圖；

3.2.2 引入服務(wù)規(guī)約，以文檔型對(duì)照代碼業(yè)務(wù)功能實(shí)現(xiàn)。有助于開(kāi)發(fā)及后續(xù)需求梳理，同時(shí)也能作為單元測(cè)試覆蓋度的考量。

• 3.2.2.1 團(tuán)隊(duì)成員共識(shí)，需求先寫服務(wù)規(guī)約，再做開(kāi)發(fā)。寫服務(wù)規(guī)約的時(shí)間，其實(shí)就是技術(shù)對(duì)需求理解的梳理，理清了思路，后續(xù)寫代碼時(shí)把這部分時(shí)間賺回來(lái)。
• 3.2.2.2 服務(wù)規(guī)約及需求，服務(wù)規(guī)約即對(duì)應(yīng)單測(cè)。順帶解決了先前單測(cè)沒(méi)有標(biāo)準(zhǔn)(我理解的代碼、方法覆蓋率這類，不能稱作為標(biāo)準(zhǔn))的問(wèn)題。

這里給出我們團(tuán)隊(duì)采用的服務(wù)規(guī)約模板：

編號(hào)：標(biāo)記業(yè)務(wù)服務(wù)的唯一編號(hào)。

名稱：動(dòng)詞短語(yǔ)形式的業(yè)務(wù)服務(wù)名。

描述：

         作為<角色>

         我想要<服務(wù)功能>

          以便于<服務(wù)價(jià)值>

觸發(fā)事件：

角色主動(dòng)觸發(fā)的該業(yè)務(wù)服務(wù)事件，可以是點(diǎn)擊UI的控件、具體的策略或伴生系統(tǒng)發(fā)送的消息等。

基本流程：

用于表現(xiàn)業(yè)務(wù)服務(wù)的主流程，即執(zhí)行成功的業(yè)務(wù)場(chǎng)景。也可以稱之為“主成功場(chǎng)景”。

替代流程：

用于表現(xiàn)業(yè)務(wù)服務(wù)的擴(kuò)展流程，即執(zhí)行失敗的業(yè)務(wù)場(chǎng)景。

驗(yàn)收標(biāo)準(zhǔn)：

一系列可以接受的條件或業(yè)務(wù)規(guī)則，以要點(diǎn)形式列舉。

3.3第三步確定架構(gòu)方案

學(xué)習(xí)DDD中模型驅(qū)動(dòng)設(shè)計(jì)元模型的方案。主要是劃分職責(zé)邊界，也就是限界上下文，達(dá)到從傳統(tǒng)網(wǎng)狀結(jié)構(gòu)關(guān)系變?yōu)榇怪鼻蟹株P(guān)系，減少彼此依賴。整體采用限界上線文拆解加菱形驅(qū)動(dòng)設(shè)計(jì)，形成整體思想指導(dǎo)。系統(tǒng)采用分層架構(gòu) COLA 4.0

3.4第四步共識(shí)命名標(biāo)準(zhǔn)形成團(tuán)隊(duì)編碼規(guī)范

 團(tuán)隊(duì)內(nèi)共識(shí)包命名、類命名、出參入?yún)⒌南⑵跫s等規(guī)范。這里想說(shuō)的是參考標(biāo)準(zhǔn)就是沒(méi)有標(biāo)準(zhǔn)。希望大家先能理解DDD思想，然后參照學(xué)習(xí)業(yè)內(nèi)共識(shí)性高的命名方案。同時(shí)需要兼顧團(tuán)隊(duì)內(nèi)成員編程風(fēng)格喜好，最終來(lái)制定自己團(tuán)隊(duì)的編碼規(guī)范。

依我們?nèi)雲(yún)ⅰ⒊鰠⑾⒚麃?lái)舉例。綜合各方考量，并沒(méi)有采用上圖粒度特別細(xì)的命名方式。而是團(tuán)隊(duì)內(nèi)簡(jiǎn)單共識(shí)為入?yún)?request，出參*reponse命名標(biāo)準(zhǔn)。

3.5第五步結(jié)合業(yè)務(wù)特征識(shí)別出限界上下文

 基于DDD思想，對(duì)業(yè)務(wù)進(jìn)行事件風(fēng)暴，在統(tǒng)一語(yǔ)言的指導(dǎo)下做全局需求分析、架構(gòu)映射設(shè)計(jì)，識(shí)別出業(yè)務(wù)的限界上下文。

技術(shù)同學(xué)結(jié)合自身業(yè)務(wù)來(lái)設(shè)計(jì)，參照Demo資料還是比較容易找的到，這里不再贅述。這里給出識(shí)別限界上下文的一個(gè)指導(dǎo)過(guò)程，V型映射過(guò)程。

3.6最后進(jìn)入建模的實(shí)現(xiàn)階段

建議采測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的方式進(jìn)行編碼，即用紅綠黃驅(qū)動(dòng)；

該方式遵循其三定律，這樣能改善對(duì)需求的設(shè)計(jì)不足和過(guò)度設(shè)計(jì)問(wèn)題。

4.對(duì)團(tuán)隊(duì)帶來(lái)的提升

4.1被動(dòng)接收需求到主動(dòng)應(yīng)對(duì)

 需求分析階段，運(yùn)用5W原則。剖析需求的合理性，能主動(dòng)把控項(xiàng)目的變化方向。解決“挑戰(zhàn)三”對(duì)需求價(jià)值辨別和改善了“挑戰(zhàn)四”的把控業(yè)務(wù)發(fā)展變化方向。

4.2降低溝通成本

運(yùn)用統(tǒng)一語(yǔ)言思想溝通，降低“挑戰(zhàn)五”的各個(gè)環(huán)節(jié)的協(xié)作成本。

4.3架構(gòu)設(shè)計(jì)提升

通過(guò)設(shè)計(jì)元模型的子領(lǐng)域模型、限界上下文合理拆解代碼規(guī)模。通過(guò)DDD的分層思想，隔離業(yè)務(wù)邏輯與技術(shù)維度復(fù)雜度，清晰代碼結(jié)構(gòu)。同時(shí)項(xiàng)目采用菱形對(duì)稱結(jié)構(gòu)，通過(guò)南北向網(wǎng)關(guān)與外部交互，避免了模塊的網(wǎng)狀情況滋生。解決了“挑戰(zhàn)二”問(wèn)題和降低了“挑戰(zhàn)一”復(fù)雜度問(wèn)題。

4.4技術(shù)實(shí)現(xiàn)提升

團(tuán)隊(duì)在開(kāi)發(fā)業(yè)務(wù)功能時(shí)，會(huì)考慮需求放到那個(gè)限界合理。實(shí)現(xiàn)過(guò)程會(huì)考慮放到領(lǐng)域?qū)舆€是業(yè)務(wù)服務(wù)層，功能的實(shí)現(xiàn)上采用貧血模型還是充血。

4.5 文檔規(guī)范提升

文檔規(guī)范上，引入服務(wù)規(guī)約機(jī)制。既能作為梳理需求的工具，又能作為單測(cè)的依據(jù)。同時(shí)還為后期提供了服務(wù)說(shuō)明的文檔。

4.6代碼實(shí)現(xiàn)提升

代碼實(shí)現(xiàn)上，從架構(gòu)到編碼實(shí)現(xiàn)、命名，形成了一套有標(biāo)注的規(guī)范。

總的來(lái)說(shuō)，該模式下，團(tuán)隊(duì)的思維方式發(fā)生了轉(zhuǎn)變。通過(guò)應(yīng)用各類元模型，來(lái)應(yīng)對(duì)從需求分析到系統(tǒng)架構(gòu)、代碼實(shí)現(xiàn)不同環(huán)節(jié)帶來(lái)的挑戰(zhàn)。

 5.理論到實(shí)戰(zhàn)遇到的沖突 

5.1貧血模型 PK 充血模型

 貧血模型：通俗來(lái)說(shuō)，就是domain object只有屬性的getter/setter方法的純數(shù)據(jù)類，業(yè)務(wù)邏輯和應(yīng)用邏輯都放到服務(wù)層中，這種模型下的domain object被Martin Fowler稱之為“貧血的domain object”。

充血模型：反之，充血模型中不僅包含了對(duì)象的屬性，還包含了對(duì)象的行為，包括業(yè)務(wù)邏輯。

從面向?qū)ο蠼嵌确治?，?duì)象是包含屬性和行為的，理應(yīng)是使用充血模型，并且DDD原則上也是建議采用充血模型。但落地到具體開(kāi)發(fā)現(xiàn)狀，即便是貧血模型有很多問(wèn)題，但業(yè)內(nèi)存在這么多年、運(yùn)用這么普遍，總歸是有其存在的價(jià)值。加上JAVA應(yīng)用大部分采用Mybatis技術(shù)棧，很多對(duì)象是插件自動(dòng)生成的貧血實(shí)體。所以問(wèn)題來(lái)了，采用充血模型意味著一部分便利工具的廢棄。這個(gè)問(wèn)題團(tuán)隊(duì)內(nèi)分歧比較大。最終我們的方式是這部分不做硬性標(biāo)準(zhǔn)，但建議使用充血模式。

5.2嚴(yán)格遵守?cái)?shù)據(jù)轉(zhuǎn)換約束  

PK 精簡(jiǎn)提效的外部數(shù)據(jù)直接使用

在DDD的思想中，為了確保領(lǐng)域服務(wù)的可靠性。要求領(lǐng)域服務(wù)依賴的數(shù)據(jù)為領(lǐng)域內(nèi)的實(shí)體、聚合數(shù)據(jù)，不允許直接使用外部的消息鍥約數(shù)據(jù)。對(duì)應(yīng)到菱形對(duì)稱架構(gòu)的南北向網(wǎng)關(guān)獲取數(shù)據(jù)的轉(zhuǎn)換，會(huì)帶來(lái)額外的工作量。有團(tuán)隊(duì)同學(xué)建議某些相對(duì)穩(wěn)定的結(jié)構(gòu)可以不遵守該原則，理由是能提高開(kāi)發(fā)速度，且認(rèn)為可能90%的數(shù)據(jù)都是如數(shù)據(jù)庫(kù)這類結(jié)構(gòu)較為穩(wěn)定的資源。但最終團(tuán)隊(duì)內(nèi)還是嚴(yán)格要求遵守該指導(dǎo)思想。

5.3緩存處理允許共享 PK 限界隔離

同一系統(tǒng)不同限界中緩存處理：允許共享 PK 各限界隔離。

就當(dāng)時(shí)場(chǎng)景來(lái)看，允許共享短期內(nèi)能減少部分工作量、節(jié)約資源等優(yōu)勢(shì)。但之所以要?jiǎng)澐窒藿?，就是為了拆解關(guān)系防止過(guò)大。這里給到的建議是，首先考慮共用數(shù)據(jù)的服務(wù)是不是合并為一個(gè)限界比較合理。如果不能合并，必須隔離數(shù)據(jù)。

5.4服務(wù)規(guī)約對(duì)照需求的前端 PK 后端

 指導(dǎo)理論思想很美好，需求分析時(shí)要求屏蔽技術(shù)實(shí)現(xiàn)思維。但終歸是要落地到技術(shù)棧的，落地到技術(shù)實(shí)現(xiàn)時(shí)就會(huì)受技術(shù)實(shí)現(xiàn)的干擾。當(dāng)時(shí)比較突出的一個(gè)問(wèn)題，功能的實(shí)現(xiàn)可以放到前端，也可以后端服務(wù)實(shí)現(xiàn)。

舉例一：需求要求“id+名字”組合展示，但是后端接口返回的id、名字兩個(gè)字段，實(shí)際前端技術(shù)棧來(lái)組合，那面向前端與后端的服務(wù)規(guī)約不一致。

舉例二：需求要求驗(yàn)證參數(shù)非空。在一些內(nèi)部系統(tǒng)中，我們團(tuán)隊(duì)技術(shù)都是前后端全棧工程師，分工按需求模塊開(kāi)發(fā)。往往不會(huì)特別嚴(yán)謹(jǐn)?shù)絻啥硕甲鲵?yàn)證。也導(dǎo)致服務(wù)規(guī)約面向哪端有沖突。

我們最終的取舍：團(tuán)隊(duì)采用面向后端服務(wù)層面。但同時(shí)做一些改進(jìn)，如驗(yàn)證這類功能轉(zhuǎn)移到接口層面來(lái)實(shí)現(xiàn)。

5.5誰(shuí)來(lái)確保服務(wù)規(guī)約編寫是否正確產(chǎn)品PK 技術(shù)

 最開(kāi)始階段理想狀態(tài)是由需求側(cè)產(chǎn)品來(lái)核驗(yàn)，本著誰(shuí)的需求誰(shuí)確認(rèn)原則。但由于存在4.4的差異問(wèn)題，我們實(shí)際落地是由技術(shù)負(fù)責(zé)人來(lái)審核。

6.未來(lái)在DDD應(yīng)用方面的改進(jìn)和總結(jié)

DDD的應(yīng)用，團(tuán)隊(duì)目前做到了從架構(gòu)和規(guī)范上面進(jìn)行落地。但一些細(xì)節(jié)如：聚合類、實(shí)體、值對(duì)象這些設(shè)計(jì)，并沒(méi)有特別精細(xì)。后期會(huì)進(jìn)一步推進(jìn)在這些細(xì)粒度上面的改進(jìn)。同時(shí)，對(duì)一些在用的老項(xiàng)目，按照DDD思想進(jìn)行改造重構(gòu)。

有人認(rèn)為應(yīng)用DDD會(huì)降低開(kāi)發(fā)效率，這個(gè)也是很多團(tuán)隊(duì)的一個(gè)顧慮。我們是這么看待這個(gè)問(wèn)題的，應(yīng)用DDD的場(chǎng)景是解決復(fù)雜性業(yè)務(wù)問(wèn)題的，確實(shí)是會(huì)增加代碼量。但不等于降低開(kāi)發(fā)效率。清晰的架構(gòu)結(jié)構(gòu)、聚合的領(lǐng)域服務(wù)和規(guī)范的標(biāo)準(zhǔn)，對(duì)后期需求升級(jí)、代碼維護(hù)、復(fù)雜度控制帶來(lái)的收益，遠(yuǎn)大于投入。并且，軟件行業(yè)給出的數(shù)據(jù)，80%的時(shí)間是在需求分析和設(shè)計(jì)，開(kāi)發(fā)時(shí)間只占到20%。因此這部分損耗不是重點(diǎn)。

最后，陳述一下使用DDD的感受。DDD各種元模型種類繁多，大家可以根據(jù)業(yè)務(wù)面臨的痛點(diǎn)有目的來(lái)學(xué)習(xí)和采用。在實(shí)際的業(yè)務(wù)環(huán)境中，我們的領(lǐng)域模型或多或少的都有一定的“特殊性”，如果100%的要符合DDD規(guī)范可能成本會(huì)比較高，所以最主要的是理解DDD思想，最終選擇合適自身業(yè)務(wù)的方案。

作者簡(jiǎn)介

李曉華 

• 經(jīng)銷商事業(yè)部-經(jīng)銷商技術(shù)部。
• 2016年加入汽車之家，目前任職于經(jīng)銷商數(shù)據(jù)架構(gòu)組團(tuán)隊(duì)，負(fù)責(zé)電話機(jī)器人項(xiàng)目。