北京2020年(nian)12月19日 /美通(tong)社/ -- 2020年(nian)12月19日，第四屆(jie)領域驅動設(she)(she)計峰會(hui)（DDD Conference）再(zai)度開啟。不(bu)同于往屆(jie)的(de)線下舉行形(xing)式，本屆(jie)峰會(hui)采取線上的(de)形(xing)式，致(zhi)力(li)于打造一場架構設(she)(she)計和技(ji)術(shu)實踐的(de)盛宴。作為軟件架構設(she)(she)計新的(de)潮流，領域驅動設(she)(she)計（Domain Driven Design，簡稱DDD）強調業(ye)務和技(ji)術(shu)的(de)統一性，為復(fu)雜領域軟件工程的(de)設(she)(she)計決策(ce)提供(gong)實踐框(kuang)架，幫助企業(ye)不(bu)斷拓展數字化業(ye)務。

2020年，一(yi)場(chang)突如其來的(de)(de)全球公(gong)共衛生(sheng)(sheng)事件(jian)對(dui)(dui)(dui)于人們的(de)(de)生(sheng)(sheng)活與工作(zuo)產(chan)生(sheng)(sheng)了(le)巨(ju)大的(de)(de)影響，各(ge)行(xing)各(ge)業積極應對(dui)(dui)(dui)挑戰。業務(wu)的(de)(de)劇變對(dui)(dui)(dui)架構(gou)平臺(tai)帶(dai)來了(le)巨(ju)大的(de)(de)沖擊，如何客觀地(di)評估(gu)分(fen)析架構(gou)現狀、該從(cong)哪些維度(du)設定架構(gou)演進的(de)(de)目(mu)標，又如何引導架構(gou)增量地(di)向目(mu)標演進，成(cheng)為當下企業持(chi)續(xu)探索的(de)(de)命(ming)題(ti)之一(yi)。

領(ling)域驅動設(she)(she)計峰(feng)會(hui)（DDD Conference）是由國內(nei)領(ling)域驅動設(she)(she)計（DDD）思想和實(shi)(shi)踐(jian)的(de)領(ling)軍(jun)者——ThoughtWorks的(de)架構咨(zi)詢師們組織發起，希望為(wei)國內(nei)的(de)領(ling)域驅動設(she)(she)計（DDD） 實(shi)(shi)踐(jian)者們提供(gong)一個互相(xiang)交流、分享(xiang)自己團隊的(de)成功(gong)經(jing)驗的(de)平臺，使得領(ling)域驅動設(she)(she)計（DDD）的(de)架構思想能夠(gou)在國內(nei)被更多人所認(ren)知，從(cong)而形(xing)成更大的(de)規模效應。

六大主題分享全景呈現DDD新常態

本屆峰會邀請了ThoughtWorks全球(qiu)技術(shu)總監及軟件架構(gou)師(shi)(shi)Neal Ford、Unisys首席(xi)應用(yong)架構(gou)師(shi)(shi)與全球(qiu)DDD社區領(ling)袖Indu Alagarsamy等(deng)來自海外的領(ling)域(yu)驅動設(she)計（DDD）的領(ling)軍人物分享在架構(gou)設(she)計領(ling)域(yu)出現(xian)的新的嘗(chang)試和(he)探索。

同時，民航(hang)信息技術總(zong)監張逸、IBM資深應用(yong)架(jia)構師于靜、《中臺架(jia)構與實現(xian)：基于DDD和(he)(he)(he)微服務》作(zuo)者歐創新(xin)等(deng)國內(nei)持(chi)續實踐領(ling)域驅動設計（DDD）的(de)代(dai)表和(he)(he)(he)思想領(ling)袖也分享了(le)他們在(zai)各(ge)個(ge)不(bu)同場(chang)景下對于使用(yong)領(ling)域驅動設計的(de)感悟(wu)和(he)(he)(he)總(zong)結，展現(xian)了(le)在(zai)后疫情時代(dai)領(ling)域驅動設計將會(hui)出現(xian)的(de)新(xin)變化。

不論(lun)是(shi)演講嘉賓(bin)還是(shi)話(hua)題設置，本次峰(feng)會既呈現了(le)(le)DDD的現狀與未(wei)來趨(qu)勢，又展示了(le)(le)DDD的最佳行業實踐，全方位呈現了(le)(le)DDD的發展情況。

構建演進式架構

在(zai)(zai)過去十年中，DDD的(de)限(xian)界(jie)上下文概念(nian)影響了軟(ruan)件(jian)(jian)(jian)(jian)架(jia)構(gou)(gou)，并(bing)啟發Neal Ford產(chan)生了《演(yan)進式(shi)架(jia)構(gou)(gou)》書中的(de)一些思想。作為ThoughtWorks全球技術總監及(ji)(ji)軟(ruan)件(jian)(jian)(jian)(jian)架(jia)構(gou)(gou)師(shi)，Neal Ford是國際公(gong)認的(de)軟(ruan)件(jian)(jian)(jian)(jian)開發和(he)(he)交(jiao)付方面(mian)的(de)專家，尤其(qi)是在(zai)(zai)敏(min)捷工程技術和(he)(he)軟(ruan)件(jian)(jian)(jian)(jian)體系結構(gou)(gou)的(de)交(jiao)集方面(mian)，以及(ji)(ji)DDD如何啟發他產(chan)生了軟(ruan)件(jian)(jian)(jian)(jian)架(jia)構(gou)(gou)的(de)量子概念(nian)。

業務(wu)實(shi)踐在(zai)(zai)變，工具(ju)和(he)框架(jia)(jia)在(zai)(zai)演進，創(chuang)新(xin)的(de)工具(ju)和(he)技術不斷涌現，這(zhe)讓軟(ruan)件開(kai)發生(sheng)態體系也是瞬(shun)息(xi)萬變。在(zai)(zai)過(guo)去的(de)幾年(nian)里，軟(ruan)件開(kai)發核心工程(cheng)實(shi)踐的(de)漸進發展，讓開(kai)發者重(zhong)新(xin)思考架(jia)(jia)構(gou)是如何隨著(zhu)時間的(de)推移而(er)變化的(de)，以及重(zhong)要的(de)架(jia)(jia)構(gou)特征如何能夠在(zai)(zai)架(jia)(jia)構(gou)演進過(guo)程(cheng)中得到有(you)效保護(hu)，這(zhe)促使Neal Ford與ThoughtWorks全球(qiu)CTO Rebecca Parson博士一起總結提煉了演進式架(jia)(jia)構(gou)的(de)核心概念。

在(zai)峰會的(de)主題分(fen)享(xiang)上，Neal Ford討論了(le)有(you)關可演(yan)進(jin)(jin)架(jia)(jia)構(gou)的(de)兩個(ge)關鍵洞察。Neal Ford指出，演(yan)進(jin)(jin)式架(jia)(jia)構(gou)是在(zai)當需求(qiu)出現的(de)時(shi)候通過適應函(han)數來(lai)把握架(jia)(jia)構(gou)演(yan)進(jin)(jin)的(de)方(fang)向，演(yan)進(jin)(jin)式架(jia)(jia)構(gou)隨著系(xi)統和業務的(de)增(zeng)加(jia)而(er)變化(hua)，而(er)且(qie)能夠保證用戶得到想(xiang)要的(de)部分(fen)，追求(qiu)性(xing)能上的(de)優化(hua)，追求(qiu)擴(kuo)展性(xing)的(de)不斷提升。

演進式架構(gou)支持(chi)跨多個維度(du)的引導性(xing)增量(liang)更改。演進架構(gou)從進化(hua)計算世界(jie)借鑒(jian)了(le)適應(ying)度(du)函數的概(gai)念，以定義所(suo)謂(wei)的架構(gou)適應(ying)性(xing)功能(neng)。這是對某些架構(gou)特性(xing)或架構(gou)特性(xing)組合(he)提供客觀完(wan)整(zheng)性(xing)評估(gu)的一(yi)種(zhong)機制，描述了(le)一(yi)系(xi)列可(ke)用(yong)于驗證體系(xi)結構(gou)適用(yong)性(xing)的工具。

Neal Ford表示，原子適(shi)應(ying)度功(gong)能是僅(jin)關注單個特(te)征(zheng)(zheng)和體(ti)系結(jie)構的(de)功(gong)能，而整(zheng)體(ti)適(shi)應(ying)性功(gong)能則關注特(te)征(zheng)(zheng)的(de)組(zu)合，很多時候體(ti)系結(jie)構特(te)征(zheng)(zheng)相互(hu)糾纏。一旦定義了這些架構適(shi)應(ying)性功(gong)能，企(qi)業(ye)需要持續集(ji)成、部署管道以及諸如此類的(de)敏(min)捷調(diao)整(zheng)實(shi)踐的(de)領域。

演進式架(jia)構最初目的是(shi)(shi)研究適應度函數的可演進性(xing)，在(zai)此(ci)過程(cheng)中，我們希(xi)望能(neng)夠(gou)衡量(liang)特定架(jia)構風格(ge)的演進程(cheng)度，雖然產生(sheng)了許多(duo)代碼級(ji)量(liang)度，但(dan)是(shi)(shi)這(zhe)還不夠(gou)。受到DDD的啟發，Neal Ford提(ti)出(chu)了軟件架(jia)構的量(liang)子概念。

架(jia)(jia)(jia)構(gou)量(liang)(liang)子是一種以軟件架(jia)(jia)(jia)構(gou)表示(shi)的(de)(de)領域驅(qu)動設計中的(de)(de)有(you)限(xian)上下(xia)文的(de)(de)想法。架(jia)(jia)(jia)構(gou)量(liang)(liang)子具有(you)高功(gong)能凝聚力和(he)同(tong)步通信的(de)(de)獨(du)立可部署組件。架(jia)(jia)(jia)構(gou)量(liang)(liang)子關注事(shi)物如何(he)耦合在(zai)一起，不(bu)僅(jin)分析了架(jia)(jia)(jia)構(gou)，而(er)且還分析了操作級別，并包含了數據庫和(he)用戶界面等內容。

“架構量子對有(you)(you)限(xian)上下文的(de)定義會(hui)有(you)(you)所不同(tong)，因為(wei)我們正(zheng)試(shi)圖衡量事物在生態系統中的(de)耦合(he)程度。我們確實想要(yao)一個有(you)(you)界上下文的(de)概念，但要(yao)用架構術(shu)語(yu)來表達(da)。我們希望它作為(wei)一個有(you)(you)用的(de)架構分(fen)析工具。”Neal Ford說。

領域驅動設計和消息傳遞的融合

DDD不僅可以幫助企(qi)業敏捷地(di)編(bian)寫(xie)高質量(liang)的(de)代碼，還(huan)能使所編(bian)寫(xie)的(de)軟件能靈活應對業務變化。當使用消(xiao)息傳遞技術在清晰整潔和定義良好的(de)限(xian)界上(shang)下(xia)文(wen)之間進行通信時(shi)(shi)，就(jiu)可以消(xiao)除(chu)時(shi)(shi)序上(shang)的(de)耦合，結合DDD就(jiu)能構建(jian)可以自治的(de)微服務。

Unisys首(shou)席應用(yong)架構(gou)師、全球(qiu)DDD社區(qu)領袖Indu Alagarsamy在分享中(zhong)認為，DDD與作為軟(ruan)件技術(shu)的消息(xi)傳遞(di)進行融合，也就是實現領域(yu)驅(qu)動設計與事件驅(qu)動架構(gou)相結合，構(gou)建可(ke)以隨著(zhu)業務變化而擴展的可(ke)靠系統。

Indu Alagarsamy還以電商場景進(jin)行了詳細說明，銷(xiao)售(shou)、庫存、運輸等(deng)不(bu)(bu)同(tong)(tong)部門(men)的(de)員工(gong)使用的(de)領域(yu)(yu)語言(yan)不(bu)(bu)同(tong)(tong)，領域(yu)(yu)驅動(dong)設(she)計(ji)引(yin)入了限界(jie)上下文(wen)的(de)概念。我們可以根據團隊或部門(men)拆分(fen)模型(xing)，進(jin)行上下文(wen)的(de)劃(hua)分(fen)和設(she)計(ji)。這(zhe)時(shi)上下文(wen)之間需要能夠以一種自(zi)主(zhu)且(qie)可靠(kao)的(de)方式進(jin)行通信，這(zhe)是事件驅動(dong)架構很好地(di)與(yu)領域(yu)(yu)驅動(dong)設(she)計(ji)結合的(de)地(di)方。

命令(ling)和事(shi)件都(dou)是消息(xi)，但是通過明(ming)確區分什么(me)是命令(ling)、什么(me)是事(shi)件，可以(yi)幫助(zhu)我(wo)們更好地設計(ji)軟件。然而如何設計(ji)一個具有事(shi)件、消息(xi)和命令(ling)的(de)系統呢？這就需要引入事(shi)件風(feng)暴(bao)。事(shi)件風(feng)暴(bao)是一種了(le)解業務流(liu)程的(de)協作可視化方式(shi)，在討論流(liu)程中的(de)業務行為時，使(shi)用事(shi)件風(feng)暴(bao)，程序員和架(jia)構師能夠(gou)找出信息(xi)流(liu)。

“我們要做的是編寫符合業務需求的正確軟件，了解重要的業務行為有助于編寫正確的代碼，并使軟件與業務保持一致，事件和消息驅動架構可以幫助我們擺脫時間耦合，使軟件組件具有自主性。隨著對領域相關信息的了解越來越多，你可以不斷的改進模型，使其變的(de)更好。如果你想使模型中的上下文(wen)自治(zhi)，可(ke)以(yi)使用事件在這些不同的限界上下文(wen)之間進(jin)行通信。”Indu Alagarsamy說。

同時，Indu Alagarsamy認為，微服務的本質在于服務需要(yao)(yao)(yao)自治，并可以根據(ju)數(shu)據(ju)做出決定，不需要(yao)(yao)(yao)不停地(di)詢問其他上(shang)下文(wen)(wen)。因(yin)此，事件作(zuo)為在相同的限界上(shang)下文(wen)(wen)中進行(xing)通信的機制(zhi)，變得非常重(zhong)要(yao)(yao)(yao)。

領域驅動設計大揭秘

作(zuo)為《解構領(ling)(ling)域驅動(dong)(dong)設計》作(zuo)者，同時也是(shi)民(min)航(hang)信(xin)息技(ji)術總監(jian)，張逸對于DDD有(you)著自(zi)己的獨特看(kan)法，比如數據驅動(dong)(dong)與(yu)領(ling)(ling)域驅動(dong)(dong)、領(ling)(ling)域驅動(dong)(dong)設計下的單體(ti)架構等。

張逸在主題分享中表示，數據驅動進入(ru)架構(gou)(gou)設(she)計(ji)領(ling)域造成模(mo)型(xing)沒有上下(xia)文(wen)的(de)(de)邊界，而(er)DDD引入(ru)了限(xian)界上下(xia)文(wen)，通過(guo)業務(wu)能力完成重用，進而(er)確定領(ling)域模(mo)型(xing)的(de)(de)知識語境，讓架構(gou)(gou)順(shun)應業務(wu)的(de)(de)變化方(fang)向。

DDD的(de)(de)(de)特點(dian)與價值(zhi)在于它(ta)定義的(de)(de)(de)模(mo)(mo)式(shi)，限界上下(xia)文(wen)與聚合(he)是(shi)(shi)DDD的(de)(de)(de)核心模(mo)(mo)式(shi)。限界上下(xia)文(wen)是(shi)(shi)架構層次(ci)的(de)(de)(de)自治單(dan)元，是(shi)(shi)業(ye)務能力(li)的(de)(de)(de)重用(yong)而非模(mo)(mo)型(xing)的(de)(de)(de)重用(yong)。而微服務的(de)(de)(de)協作就是(shi)(shi)限界上下(xia)文(wen)的(de)(de)(de)協作，領域驅動(dong)設計成為(wei)顯學(xue)，進入黃金時代。

單(dan)體架(jia)構（Monolithic Architecture）是一種將所(suo)有(you)功(gong)能打包在一個(ge)容器中運行的設計風格，一個(ge)實例中集成了一個(ge)系統(tong)的所(suo)有(you)功(gong)能。從中大型項目的業(ye)務(wu)形(xing)態(tai)、復(fu)雜(za)度(du)及響應速度(du)等維(wei)度(du)看單(dan)體架(jia)構時可以發現它存在擴展性差、無(wu)法實現復(fu)雜(za)業(ye)務(wu)、技術升級(ji)困(kun)難(nan)、開發效率低等問題。

張逸表示，常見的區分單(dan)(dan)體(ti)架(jia)構(gou)(gou)和微服務(wu)架(jia)構(gou)(gou)的做法并不正確，雖然沒有(you)限界上(shang)下文的單(dan)(dan)體(ti)架(jia)構(gou)(gou)可(ke)能(neng)導致“大泥球”，但是單(dan)(dan)體(ti)架(jia)構(gou)(gou)也(ye)要通過業務(wu)能(neng)力進(jin)(jin)行縱向切分。如果單(dan)(dan)體(ti)架(jia)構(gou)(gou)通過限界上(shang)下文進(jin)(jin)行邊界控制，其實(shi)可(ke)以降(jiang)低微服務(wu)架(jia)構(gou)(gou)風格的演化成本，也(ye)能(neng)規避過度微服務(wu)化帶來的技(ji)術(shu)風險。

另外，張逸認(ren)為，領(ling)(ling)域(yu)驅動設(she)計(ji)(ji)存在四大“天生不(bu)足”，比如領(ling)(ling)域(yu)驅動設(she)計(ji)(ji)缺(que)乏一個(ge)規(gui)范的過程指導，使得其缺(que)乏可操作性；領(ling)(ling)域(yu)驅動設(she)計(ji)(ji)沒有匹(pi)配的需(xu)求(qiu)管(guan)理體系等，為此，我們需(xu)要領(ling)(ling)域(yu)驅動設(she)計(ji)(ji)統一過程，確保(bao)DDD的落地實(shi)施。

領域驅動設計在大型遺留系統改造中的實踐

自領域(yu)驅動(dong)設計(ji)和微(wei)服(fu)(fu)務(wu)概念提(ti)出至今，越(yue)來越(yue)多的(de)互聯網巨(ju)頭以及傳統(tong)行業(ye)都開始對(dui)自己的(de)遺留(liu)系(xi)統(tong)進行微(wei)服(fu)(fu)務(wu)改(gai)造，通過把系(xi)統(tong)拆分(fen)為更加靈活(huo)、有(you)業(ye)務(wu)邊界(jie)上下文、松耦合的(de)服(fu)(fu)務(wu)來應對(dui)快(kuai)速變化的(de)市場。

IBM資深應用架構師于靜在(zai)主題(ti)演講中(zhong)介紹(shao)了一個有著二十年(nian)歷史并支(zhi)撐百萬(wan)交易額的(de)(de)電商平臺如何通(tong)過DDD方法華麗轉身的(de)(de)實踐，從這個案例我(wo)們了解到(dao)遺留(liu)系統進行DDD改造過程中(zhong)的(de)(de)點(dian)滴經(jing)驗。

于靜表(biao)示，為(wei)了加速數字化轉型與業務模式(shi)創新實現(xian)，遺(yi)留系統的改造(zao)會面臨(lin)很多難(nan)題，比如(ru)交付(fu)速度(du)慢、應用架構不滿足快速迭代需求(qiu)、技術受限、維護(hu)成本高、業務流程復(fu)雜等。而在改造(zao)過程中，現(xian)有業務不能停，同時過程難(nan)控制(zhi)、結(jie)果難(nan)驗證等問題也非(fei)常突出(chu)。

為此(ci)，遺留系(xi)統(tong)改(gai)造(zao)實施(shi)需要確立目標(biao)與(yu)制定(ding)策略、業(ye)(ye)務(wu)梳理、服務(wu)改(gai)造(zao)、集(ji)成遷移測試、反饋。在DDD指導(dao)下，企業(ye)(ye)需要通過事件風暴對業(ye)(ye)務(wu)討論，審視現有的業(ye)(ye)務(wu)邏輯，逐(zhu)步用新應用程序和服務(wu)替換(huan)特定(ding)功(gong)能(neng)段，增量遷移舊系(xi)統(tong)。隨著舊系(xi)統(tong)功(gong)能(neng)的更換(huan)，新系(xi)統(tong)最(zui)終(zhong)取代了所有舊系(xi)統(tong)功(gong)能(neng)。

于(yu)靜說(shuo)，企業在遺留系統改造中(zhong)應該遵(zun)循“先(xian)鋒(feng)隊(dui)、樹立(li)模(mo)范、大(da)部隊(dui)”的(de)階段性原則。具體來說(shuo)，“先(xian)鋒(feng)隊(dui)”階段是(shi)挑選規模(mo)較小、功能簡單，業務較為(wei)獨立(li)的(de)功能模(mo)塊進(jin)行(xing)改造，隨著老系統的(de)功能越(yue)來越(yue)多的(de)被微(wei)服(fu)務系統所代(dai)替(ti)，老系統也最終被替(ti)代(dai)。需(xu)要注意的(de)是(shi)，當發生新(xin)老系統的(de)功能切換(huan)時，應該逐步切換(huan)用戶流(liu)量，對用戶盡量透明，使得(de)改造過程過渡平(ping)滑。

當中臺遇上DDD，如何設計微服務？

當(dang)前，中臺(tai)、微(wei)服務是業界關(guan)注的熱點(dian)話題。如(ru)果將(jiang)兩(liang)者(zhe)放到(dao)DDD的背景下，如(ru)何建立DDD、中臺(tai)和微(wei)服務的統一語言？如(ru)何將(jiang)三者(zhe)融合完(wan)成協同設(she)計？《中臺(tai)架構與實(shi)現(xian)：基于DDD和微(wei)服務》作(zuo)者(zhe)、極客(ke)時間《DDD實(shi)戰課》專欄作(zuo)者(zhe)歐創新在主題分享(xiang)中回答了這些問題。

歐創(chuang)新表示，從企業(ye)(ye)架構(gou)(gou)角度(du)來講，業(ye)(ye)務(wu)中(zhong)臺(tai)屬于(yu)業(ye)(ye)務(wu)架構(gou)(gou)的(de)范疇，業(ye)(ye)務(wu)中(zhong)臺(tai)重構(gou)(gou)的(de)過程(cheng)本質是基于(yu)復(fu)用(yong)目的(de)的(de)企業(ye)(ye)級業(ye)(ye)務(wu)架構(gou)(gou)重構(gou)(gou)。在業(ye)(ye)務(wu)量不大(da)(da)的(de)時候，我們(men)用(yong)傳統的(de)集(ji)中(zhong)式架構(gou)(gou)就可以解(jie)決復(fu)雜(za)問(wen)題(ti)。而當面(mian)對(dui)海(hai)量互聯網業(ye)(ye)務(wu)比(bi)如雙十一(yi)，企業(ye)(ye)原(yuan)來的(de)架構(gou)(gou)就不足以解(jie)決業(ye)(ye)務(wu)和應(ying)用(yong)的(de)擴展性問(wen)題(ti)，因此我們(men)需要將原(yuan)來大(da)(da)的(de)問(wen)題(ti)域拆(chai)小(xiao)，將單(dan)體應(ying)用(yong)拆(chai)分為微(wei)服(fu)務(wu)，進而上云。所以，DDD和微(wei)服(fu)務(wu)都是解(jie)決復(fu)雜(za)問(wen)題(ti)的(de)設計思想。

在DDD概念里(li)，如果只從(cong)業務(wu)架(jia)構(gou)角度分析的話，中臺本質上是從(cong)領域到更(geng)細的子(zi)域劃分過程(cheng)中的一個橋梁，只從(cong)業務(wu)領域角度分析，它可能(neng)對(dui)應DDD領域中的某一個核心子(zi)域或(huo)通用子(zi)域。

對于DDD與中(zhong)(zhong)臺(tai)(tai)和微(wei)(wei)服務的關系，歐創新認(ren)為(wei)，中(zhong)(zhong)臺(tai)(tai)本(ben)質是(shi)領(ling)域(yu)(yu)中(zhong)(zhong)的某一(yi)個子(zi)域(yu)(yu)，需要抽象(xiang)并標準化，按照單一(yi)職責原(yuan)則(ze)建立可(ke)復用的領(ling)域(yu)(yu)模(mo)型。微(wei)(wei)服務是(shi)中(zhong)(zhong)臺(tai)(tai)最佳技(ji)術實現(xian)。DDD是(shi)一(yi)種可(ke)以同時(shi)指導中(zhong)(zhong)臺(tai)(tai)業務建模(mo)和微(wei)(wei)服務設(she)計的方法論，遵循(xun)高(gao)內聚低耦合的原(yuan)則(ze)，完成(cheng)從業務端(duan)領(ling)域(yu)(yu)建模(mo)到(dao)應用端(duan)微(wei)(wei)服務實現(xian)的無縫落(luo)地。

我們看到DDD和中臺(tai)設(she)計(ji)兩種知識體系(xi)的(de)融合需(xu)要建(jian)立兩者通用(yong)語言，團隊通用(yong)語言也是DDD不斷強調的(de)內容(rong)。一般對于(yu)小的(de)項目(mu)我們可(ke)以直接從(cong)問題域(yu)開始事件風暴，完成領(ling)域(yu)建(jian)模。而(er)對于(yu)企業級中臺(tai)而(er)言，業務領(ling)域(yu)非常(chang)大(da)，我們需(xu)要做好頂(ding)層設(she)計(ji)，劃(hua)(hua)分(fen)子(zi)域(yu)，確(que)定中臺(tai)的(de)大(da)致邊界，然后基(ji)于(yu)這個(ge)邊界開展事件風暴，劃(hua)(hua)分(fen)限(xian)界上下(xia)文(wen)，完成領(ling)域(yu)建(jian)模，它是一個(ge)自上而(er)下(xia)的(de)設(she)計(ji)過(guo)程。

“DDD博大精深，但DDD也(ye)不是(shi)萬能的‘銀(yin)彈(dan)’。將中(zhong)臺和(he)DDD視作(zuo)一種思維方式和(he)設計思想，結合企業實際情況靈活運用(yong)才是(shi)王道。”歐創新說。

DDD從戰略設計到代碼落地的三階段方法

ThoughtWorks總監級咨詢(xun)師楊(yang)云(yun)指導(dao)過(guo)多個DDD實施項(xiang)目的落地，在峰會的主題演講(jiang)上楊(yang)云(yun)系統介(jie)紹(shao)了如何將(jiang)DDD建模在大規模開發團隊的情況下確實的落地到代碼層面。

為什(shen)么企業覺得DDD落地(di)(di)難(nan)(nan)？楊云(yun)表(biao)示(shi)：“首先，因為DDD進入了(le)更深層的(de)(de)應用(yong)。DDD從戰略層面(mian)的(de)(de)應用(yong)進入到(dao)戰術(shu)落地(di)(di)層面(mian)，而不再僅(jin)僅(jin)停留在(zai)子域劃(hua)分(fen)、微服務劃(hua)分(fen)等。其次(ci)，參與建模(mo)(mo)(mo)的(de)(de)人(ren)，從業務專(zhuan)家和架(jia)構師(shi)級別的(de)(de)技術(shu)專(zhuan)家，深入到(dao)產品經理、軟件工(gong)程師(shi)等執行具(ju)體事務的(de)(de)人(ren)員(yuan)，面(mian)臨在(zai)百人(ren)以上開發團隊大項目上保證代碼(ma)按(an)照模(mo)(mo)(mo)型落地(di)(di)的(de)(de)難(nan)(nan)度。最后，DDD建模(mo)(mo)(mo)的(de)(de)投入和交付時間(jian)點(dian)的(de)(de)矛盾、DDD建模(mo)(mo)(mo)投入的(de)(de)即時性和DDD模(mo)(mo)(mo)型收益(yi)的(de)(de)長期性之間(jian)的(de)(de)矛盾。”

在DDD落(luo)地方面，企業需要對(dui)戰(zhan)術級別(bie)的(de)建模(mo)提(ti)供(gong)更具體、更模(mo)式化的(de)指引。對(dui)于大規模(mo)項目，設(she)計更明確、與(yu)代碼(ma)實現直接相關的(de)微觀模(mo)型。提(ti)供(gong)更好的(de)工(gong)具降低DDD模(mo)型建設(she)和(he)維護(hu)成本，提(ti)高模(mo)型和(he)代碼(ma)一(yi)致(zhi)性(xing)。

基(ji)于此(ci)，楊云(yun)提出了DDD落地的(de)三階(jie)段(duan)(duan)方法：事件風暴階(jie)段(duan)(duan)聚焦戰(zhan)略建模、子域劃分(fen)、微服務(wu)拆分(fen)；名(ming)詞(ci)動(dong)詞(ci)階(jie)段(duan)(duan)，在(zai)子域或微服務(wu)內(nei)，細化實體和(he)(he)行(xing)為，識別重(zhong)要角色和(he)(he)重(zhong)要規則，建立子域內(nei)核(he)心概念的(de)結(jie)構化模型；類型流(liu)階(jie)段(duan)(duan)，微觀展開具體行(xing)為，將承載(zai)業(ye)務(wu)邏(luo)輯(ji)的(de)純函數和(he)(he)依賴基(ji)礎設施的(de)副作用(yong)函數剝離。

楊(yang)云表示，建模(mo)(mo)是(shi)迭代的(de)，不是(shi)線(xian)性(xing)單向的(de)。DDD建模(mo)(mo)需要(yao)考(kao)慮團隊工作的(de)細(xi)節層次，采(cai)取適當的(de)方法(fa)：用(yong)事件風暴(bao)來(lai)做(zuo)(zuo)戰略建模(mo)(mo)、用(yong)名詞動詞法(fa)做(zuo)(zuo)子域內的(de)結構化戰術建模(mo)(mo)、用(yong)類型流(liu)做(zuo)(zuo)行為內部的(de)微觀詳細(xi)設計。

結語

DDD從2003年被提出(chu)來以后，得到了業界的(de)(de)高度認可，特(te)別是(shi)微服(fu)務(wu)架構、中臺等(deng)逐漸盛行，DDD正在加速(su)在企業業務(wu)實踐中的(de)(de)落地。而領域驅(qu)動設計峰會為DDD社(she)區提供了一個絕(jue)佳的(de)(de)交(jiao)流(liu)與分享平(ping)臺，也將極(ji)大推動這(zhe)種進(jin)程，更(geng)好(hao)地促進(jin)DDD的(de)(de)發展(zhan)。