為什么需要DDD？DDD怎么解決問題？

為什么需要DDD？

沒有實(shí)施DDD的情況下，我們經(jīng)常會(huì)遇到什么問題？

開發(fā)人員熱衷于技術(shù)而不是深入了解業(yè)務(wù)。這是技術(shù)人員的職責(zé)使然，一個(gè)不高級(jí)的開發(fā)，通常他的業(yè)務(wù)經(jīng)驗(yàn)不重要；一個(gè)高級(jí)的開發(fā)，通常因?yàn)楦?jìng)業(yè)，也無(wú)法繼續(xù)干類似的業(yè)務(wù)。所以開發(fā)人員對(duì)業(yè)務(wù)天然的沒有足夠的興趣。但是開發(fā)過程中，對(duì)業(yè)務(wù)不夠熟悉，很容易發(fā)現(xiàn)開發(fā)做了半天得到的，并不是用戶和產(chǎn)品想要的；或者下次再有需求的時(shí)候，技術(shù)上的改動(dòng)特別大，成本很高。

業(yè)務(wù)協(xié)作不暢，一個(gè)需求提到好幾個(gè)團(tuán)隊(duì)都能做，但是開發(fā)過程你推我我推你，需求一拖再拖，有時(shí)候項(xiàng)目中期還得找其他團(tuán)隊(duì)求資源。

對(duì)項(xiàng)目工時(shí)的估計(jì)占用了不少精力，還不準(zhǔn)確。估時(shí)這件事能成為管理層和開發(fā)人員之間的拉鋸戰(zhàn)。

服務(wù)之間緊耦合，牽一發(fā)而動(dòng)全身，一個(gè)非核心的業(yè)務(wù)抖一抖，客戶都說沒法用。

那么 DDD 怎么解決這些問題？

找到邊界：讓設(shè)計(jì)系統(tǒng)的人知道一個(gè)業(yè)務(wù)的邊界在哪里。只有知道邊界在哪里，才能在需求到來(lái)的時(shí)候，輕易地找到相關(guān)團(tuán)隊(duì)，各個(gè)業(yè)務(wù)之間也才能真正解耦，降低非核心功能對(duì)核心功能的影響。

知識(shí)獲?。罕ＷC設(shè)計(jì)系統(tǒng)的人能夠低成本地了解業(yè)務(wù)，讓大家在怎么做，怎么驗(yàn)收方面達(dá)成一致。在此基礎(chǔ)上，還可以免費(fèi)得到一款評(píng)估時(shí)間的工具，項(xiàng)目的交付就更有把握。

但是在此我要多說一下，我們現(xiàn)實(shí)實(shí)踐中已經(jīng)有一部分領(lǐng)域概念的影子了——誰(shuí)能說他不知道自己的組織是干啥的？或者說哪個(gè)組織沒有業(yè)務(wù)重心呢？可是為什么大家沒有獲得上邊說的這諸多好處呢？那是因?yàn)镈DD實(shí)踐過程中巧妙地將設(shè)計(jì)模型落地成為開發(fā)的模型，讓需求方和實(shí)施方說一種語(yǔ)言，才能真正跨越了需求和實(shí)現(xiàn)之間的鴻溝。所以實(shí)踐DDD，絕不是只有開發(fā)寫寫代碼就行，而是要跟產(chǎn)品，設(shè)計(jì)以及領(lǐng)域?qū)＜乙黄鹜瓿稍O(shè)計(jì)，才能得到DDD的好處。

DDD是什么呢?

我們先看幾個(gè)*DD：

TDD 驅(qū)動(dòng)測(cè)試開發(fā)

BDD 行為驅(qū)動(dòng)開發(fā)

ADD 不是單詞Add，而是 API 驅(qū)動(dòng)開發(fā)

DDD 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

前面幾個(gè)概念落腳點(diǎn)都是開發(fā)，而DDD，是設(shè)計(jì)。

它有三個(gè)關(guān)鍵詞：領(lǐng)域，驅(qū)動(dòng)，設(shè)計(jì)。領(lǐng)域，是要探索業(yè)務(wù)的邊界；驅(qū)動(dòng),表示前者是后者的決定性因素；設(shè)計(jì)，包括產(chǎn)品設(shè)計(jì)，UIUE設(shè)計(jì)，軟件設(shè)計(jì)。它不僅僅是開發(fā)架構(gòu)的方案，而是完整的解決方案實(shí)施思路。正是因?yàn)樗峭暾姆桨?，才能讓領(lǐng)域?qū)＜?，產(chǎn)品和研發(fā)真正在同一個(gè)角度去思考和溝通，避免推諉扯皮，含糊不清。

那么怎么做DDD呢?

實(shí)施DDD一般有兩步，并且需要開發(fā)，產(chǎn)品和領(lǐng)域?qū)＜业耐献?。為了?shí)施速度有所保障，還有一些項(xiàng)目加速和項(xiàng)目管理工具：

戰(zhàn)略設(shè)計(jì)

戰(zhàn)術(shù)設(shè)計(jì)

戰(zhàn)略設(shè)計(jì)

戰(zhàn)略設(shè)計(jì)可以說是搭建了業(yè)務(wù)思想上的框架。這個(gè)階段要做這么幾件事：

使用限界上下文分離領(lǐng)域模型

在限界上下文發(fā)展通用語(yǔ)言

使用子域處理遺留系統(tǒng)

使用上下文映射來(lái)集成多個(gè)限界上下文

限界上下文分離領(lǐng)域模型

限界上下文這個(gè)名字乍一看，每個(gè)字我都認(rèn)識(shí)，但是這個(gè)詞是啥意思？原文說它是語(yǔ)義和語(yǔ)境上的邊界，我的理解是，它是在描述組織交付出來(lái)，面向客戶的交付邊界。如果是在SaaS場(chǎng)景，一個(gè)限界上下文應(yīng)該是一個(gè)獨(dú)立交付的軟件；在PaaS場(chǎng)景，它應(yīng)該說的是一個(gè)獨(dú)立售賣的模塊。它的含義是找到一個(gè)邊界，要把這個(gè)邊界以外的當(dāng)成是無(wú)法改變的客觀環(huán)境，不要幻想這個(gè)邊界以外的人會(huì)配合你一起完成交付。那這一步設(shè)計(jì)就很好理解了，就是找到你業(yè)務(wù)對(duì)外承諾的邊界，你要發(fā)展的業(yè)務(wù)在這個(gè)邊界內(nèi)，而不在此之外。如果你是對(duì)內(nèi)交付的系統(tǒng)，那么你對(duì)其他同事交付的業(yè)務(wù)邊界，就是你的業(yè)務(wù)限界上下文。

一個(gè)組織里，最核心的限界上下文被稱為核心域。通常除了它，還有通用子域和支撐子域。通用子域是很成熟的業(yè)務(wù)，通?？梢酝獍蛘哔?gòu)買現(xiàn)成的解決方案，比如搜索子域可以通過ES來(lái)支持；支撐子域通常沒有現(xiàn)成產(chǎn)品，但是它沒有核心域重要，因此也可以一定程度的外包，避免在核心域之外浪費(fèi)資源，比如大多數(shù)公司的數(shù)據(jù)庫(kù)中間件是在開源產(chǎn)品上做了一些定制開發(fā)和維護(hù)。

限界上下文這個(gè)概念的目的是為了在業(yè)務(wù)擴(kuò)展的時(shí)候，防止向領(lǐng)域內(nèi)注入概念，導(dǎo)致業(yè)務(wù)變得沒有邊界，糾纏在一起。

在做這一步的時(shí)候，DDD要求以領(lǐng)域?qū)＜乙庖姙闇?zhǔn)，正所謂領(lǐng)域驅(qū)動(dòng)嘛。當(dāng)實(shí)施了DDD方法以后，不論是領(lǐng)域?qū)＜疫€是開發(fā)，都應(yīng)該拒絕向領(lǐng)域注入與業(yè)務(wù)無(wú)關(guān)的概念，比如存儲(chǔ)方式等。這與我們?nèi)粘９ぷ鲝娜绾未鎯?chǔ)開始構(gòu)建業(yè)務(wù)系統(tǒng)是完全不同的。只有把這些技術(shù)概念放到業(yè)務(wù)之外，我們的業(yè)務(wù)核心往往才能足夠集中，易于遷移，而且不論采用什么東西存儲(chǔ)，用什么東西展示，它的邏輯都可以不變。

這個(gè)過程中我們通?？梢缘玫竭@樣一個(gè)模型：

限界上下文發(fā)展通用語(yǔ)言

當(dāng)我們有了業(yè)務(wù)的限界上下文以后，就需要在這個(gè)限界上下文中發(fā)展一種語(yǔ)言用于表達(dá)軟件模型，這個(gè)語(yǔ)言就叫做這個(gè)限界上下文里的通用語(yǔ)言。它可以是任何計(jì)算機(jī)語(yǔ)言、人類語(yǔ)言或者圖形，只要能讓團(tuán)隊(duì)內(nèi)的每個(gè)人都能看懂。

通用語(yǔ)言不止是名詞，它應(yīng)該使用一系列具體的模型場(chǎng)景來(lái)描述領(lǐng)域模型。它描述了各種業(yè)務(wù)組件（不是技術(shù)組件）做什么，而不是用例或者用戶故事。

比如微信朋友圈點(diǎn)贊這個(gè)場(chǎng)景，通用語(yǔ)言可能是：用戶可以通過點(diǎn)贊，使得某個(gè)朋友圈的Feed發(fā)出人收到被點(diǎn)贊的通知，達(dá)到互動(dòng)的目的。

但是到這一步，我們?cè)趺茨茯?yàn)證領(lǐng)域模型能與領(lǐng)域?qū)＜业男闹潜３忠恢履?？那就是為這個(gè)模型寫驗(yàn)收測(cè)試，并交由領(lǐng)域?qū)＜以u(píng)估。一種做法是驗(yàn)收測(cè)試采用given-when-then語(yǔ)法（中文可以用假如-當(dāng)-那么），便于閱讀理解。驗(yàn)收測(cè)試也可以用腦圖，文字來(lái)描述，甚至DDD不反對(duì)采用單元測(cè)試框架寫驗(yàn)收測(cè)試，只要領(lǐng)域?qū)＜夷軌蜷喿x并理解寫出的驗(yàn)收測(cè)試。

這一步做完后我們的模型圖形其實(shí)沒什么變化，但是現(xiàn)在，開發(fā)能夠更充分的了解業(yè)務(wù)了。

使用子域處理遺留系統(tǒng) 我們代碼不是在真空里運(yùn)行，它們免不了會(huì)跟一些遺留系統(tǒng)打交道，這些遺留系統(tǒng)的邊界并不清晰。因此我們會(huì)將遺留系統(tǒng)放到一個(gè)子域里，把它們的問題放到我們的設(shè)計(jì)之外。這一步做完后我們的圖案與之前沒有本質(zhì)上的區(qū)別，無(wú)非是多了一點(diǎn)子域。

使用上下文映射來(lái)集成多個(gè)限界上下文

上下文映射是兩個(gè)限界上下文之間的連線，表示了這兩個(gè)概念之間的關(guān)系，也表示這這兩個(gè)概念的通用語(yǔ)言的翻譯。通常來(lái)說，不同的限界上下文是不同的團(tuán)隊(duì)在維護(hù)，那么此時(shí)它也代表著兩個(gè)團(tuán)隊(duì)之間合作的關(guān)系。

我們常見的映射關(guān)系是RPC接口。然而在領(lǐng)域設(shè)計(jì)里，限界上下文之間使用RPC是有風(fēng)險(xiǎn)的方案，因?yàn)闀?huì)承受網(wǎng)絡(luò)風(fēng)險(xiǎn)，還意味著兩個(gè)限界上下文之間存在緊耦合。如果系統(tǒng)A阻塞請(qǐng)求系統(tǒng)B，B又請(qǐng)求C，就很容易導(dǎo)致集成火車事故：火車?yán)锬骋还?jié)車廂有問題就會(huì)變成整列火車的問題。

最好的限界上下文映射關(guān)系采用事件的訂閱，但是這要求領(lǐng)域?qū)＜以谠O(shè)計(jì)的時(shí)候就考慮不同領(lǐng)域之間通知的延遲對(duì)于業(yè)務(wù)的影響，以及如何消除影響。如果不采用DDD的方式，領(lǐng)域?qū)＜彝ǔo(wú)法意識(shí)到領(lǐng)域之間的同步成本，技術(shù)人員也很容易一頭撞進(jìn)集成火車?yán)?。這就是我說的：DDD的目標(biāo)是找到邊界和促進(jìn)學(xué)習(xí)知識(shí)，不僅僅是開發(fā)學(xué)習(xí)業(yè)務(wù)，領(lǐng)域?qū)＜乙彩窃趯W(xué)習(xí)系統(tǒng)的邊界與設(shè)計(jì)。

戰(zhàn)術(shù)設(shè)計(jì)

在戰(zhàn)術(shù)設(shè)計(jì)階段包括如下設(shè)計(jì)：

把一些實(shí)體和值對(duì)象放一起，稱為聚合。

利用領(lǐng)域事件通知相關(guān)系統(tǒng)。

聚合怎么設(shè)計(jì)

一個(gè)限界上下文里通常有多個(gè)聚合，聚合邏輯上是相對(duì)獨(dú)立的。怎么理解聚合的概念呢？在DDD實(shí)踐中，聚合是事務(wù)的邊界；聚合之間并不保證事務(wù)，只能用最終一致性。任何需要事務(wù)保護(hù)的邏輯都應(yīng)該在一個(gè)聚合內(nèi)。在限界上下文里，將其他聚合能力整合在一起對(duì)外提供能力的聚合，被稱為聚合根；其他聚合也被稱為實(shí)體。

此外，一個(gè)限界上下文里還有值對(duì)象，它也代表了某種相對(duì)獨(dú)立的概念。怎么區(qū)分實(shí)體和值對(duì)象呢？這取決于業(yè)務(wù)。如果一個(gè)名詞，具有多種動(dòng)詞去操作它，那么它應(yīng)該是一個(gè)實(shí)體；如果一個(gè)名詞，在系統(tǒng)里只是被傳遞而沒有業(yè)務(wù)邏輯，那么它就是值對(duì)象。

由于聚合是事務(wù)的邊界，那么每個(gè)聚合在設(shè)計(jì)階段，最重要的是找到業(yè)務(wù)的不變性，也就是說，在事務(wù)提交前后，數(shù)據(jù)的約束條件。比如說，你在知乎對(duì)一條回答點(diǎn)贊，那么這條回答的點(diǎn)贊數(shù)量必須立刻多1，那么點(diǎn)贊的動(dòng)作和點(diǎn)贊的計(jì)數(shù)，就應(yīng)當(dāng)在一個(gè)聚合內(nèi)。

領(lǐng)域?qū)＜冶厝幌Ｍ魏问虑槎寄茉谟|發(fā)后立刻完成，所以在溝通的過程中要不斷質(zhì)疑，如果不實(shí)時(shí)地做一件事，會(huì)不會(huì)有問題。甚至可以用一個(gè)夸張到顯然無(wú)法接受的時(shí)間長(zhǎng)度來(lái)質(zhì)疑，以促成領(lǐng)域?qū)＜覍?duì)此認(rèn)真思考。

在聚合被設(shè)計(jì)出來(lái)以后，我們的模型圖看起來(lái)會(huì)是這樣的：

領(lǐng)域事件怎么設(shè)計(jì)

我們說聚合之間要采用最終一致性，而通常的做法是采用領(lǐng)域事件實(shí)現(xiàn)最終一致性。領(lǐng)域事件的名稱應(yīng)該采用通用語(yǔ)言命名，才能符合領(lǐng)域?qū)＜业男闹?。完整的時(shí)間名詞應(yīng)該是名詞和動(dòng)詞構(gòu)成的，動(dòng)詞應(yīng)該是過去時(shí)。領(lǐng)域事件的名字和屬性應(yīng)該能夠完整描述這個(gè)事件的含義。

事件里通常至少包含業(yè)務(wù)動(dòng)作和其業(yè)務(wù)參數(shù)，也可以增加更多的下游關(guān)注的事件信息，避免下游為了完成處理還需查詢。

領(lǐng)域事件會(huì)持久保存在專門的數(shù)據(jù)表中，用來(lái)表示領(lǐng)域事件的因果關(guān)系。

有一種專門的存儲(chǔ)方式是事件溯源，它不需要存儲(chǔ)數(shù)據(jù)當(dāng)前是什么，而是從歷史事件中按順序應(yīng)用重建，得到當(dāng)前的數(shù)據(jù)。這樣寫入時(shí)的成本只有校驗(yàn)后持久化，也沒有增加和刪除的能力。如果事件很多，性能問題很大，也可以加上緩存和快照，優(yōu)化性能。這種方案通常會(huì)與CQRS方案一起做。

進(jìn)度加速和項(xiàng)目管理工具

在這本小冊(cè)子里,Evans提出了兩個(gè)工具，分別用于加速設(shè)計(jì)階段和評(píng)估工時(shí)。

事件風(fēng)暴

事件風(fēng)暴是快速的設(shè)計(jì)技術(shù)，讓領(lǐng)域?qū)＜液烷_發(fā)人員都可以參與學(xué)習(xí)，目的是在有限的時(shí)間里盡可能多地完成設(shè)計(jì)，也就是加速設(shè)計(jì)階段。

事件風(fēng)暴要先做如下準(zhǔn)備：

邀請(qǐng)領(lǐng)域?qū)＜液烷_發(fā)人員

每個(gè)成員都應(yīng)該以開放的心態(tài)參與討論，不必追求正確和速度。

各種顏色便利貼，正方形的。一般一個(gè)便利貼只會(huì)寫幾個(gè)詞。

每個(gè)人都有黑色的馬克筆。

最好有一面至少10米長(zhǎng)的墻并且鋪上白紙。最好建模的幾天時(shí)間內(nèi)保持每次討論的結(jié)果一直保留并供下次討論使用。

事件風(fēng)暴的基本步驟：

在便利貼上寫領(lǐng)域事件，梳理出業(yè)務(wù)流程，一般是橘色。

創(chuàng)建領(lǐng)域事件強(qiáng)調(diào)我們首要關(guān)注的是業(yè)務(wù)流程，而不是數(shù)據(jù)和結(jié)構(gòu)

把每個(gè)領(lǐng)域事件寫在一張便利貼上，應(yīng)該是動(dòng)詞的過去式。

把寫好的便利貼按照時(shí)間順序放到建模平面上，從左往右逐步發(fā)生。

并行發(fā)生的領(lǐng)域可以上下排列，不明白時(shí)機(jī)的事件可以單放在某個(gè)單獨(dú)的位置。

如果發(fā)現(xiàn)了問題點(diǎn)，可以用紅色的便利貼上，并用一段文字解釋是什么問題。

領(lǐng)域事件最終會(huì)觸發(fā)一個(gè)執(zhí)行的流程，每個(gè)流程都應(yīng)該命名并記錄在淺紫色的便利貼。需要從領(lǐng)域事件畫個(gè)箭頭指向這個(gè)流程。支隊(duì)核心域中非常重要的細(xì)粒度事件進(jìn)行建模。

創(chuàng)建導(dǎo)致領(lǐng)域事件發(fā)生的命令，命令應(yīng)該是指令式的。

創(chuàng)建領(lǐng)域事件的便利貼是淺藍(lán)色的。

觸發(fā)事件的便利貼放在觸發(fā)的事件左邊，會(huì)有很多成對(duì)出現(xiàn)的命令和事件。但是也有不是命令觸發(fā)的事件，比如時(shí)間觸發(fā)的事件。

如果存在一個(gè)執(zhí)行動(dòng)作的特定角色，那么可以在命令左下角使用亮黃色的便利貼記錄角色名稱。

命令也可以觸發(fā)流程。

在命令和事件之間畫出線條

按照時(shí)間順序，將命令和事件的關(guān)系處理好

一個(gè)命令可以帶來(lái)多個(gè)事件

把命令和領(lǐng)域事件通過實(shí)體、聚合聯(lián)系起來(lái)。由于建模沒完，因此沒有真正的實(shí)體和聚合，而是領(lǐng)域?qū)＜宜枷肜锏臉I(yè)務(wù)概念和概念群。用淡黃色的便利貼來(lái)表示聚合，其左下角是命令，右下角是事件。聚合的名字應(yīng)該是名詞。

在建模平面上畫出邊界和事件流動(dòng)的箭頭。

識(shí)別用戶執(zhí)行操作所需的各種視圖，以及客戶不同用戶的關(guān)鍵角色。

4和5是事件風(fēng)暴的關(guān)鍵。

時(shí)間評(píng)估工具

時(shí)間評(píng)估工具是如下的一個(gè)經(jīng)驗(yàn)表格：

作者Evans在原始表格里使用的單位是人時(shí)，然而根據(jù)我的經(jīng)驗(yàn)，這個(gè)地方用人天還差不多……

這個(gè)表格的好處是系統(tǒng)里關(guān)于業(yè)務(wù)的部分都很明確了，雖然時(shí)間還是經(jīng)驗(yàn)得出的，但是實(shí)際上已經(jīng)相對(duì)精細(xì)了，而且在領(lǐng)域內(nèi)的部分，估時(shí)會(huì)更準(zhǔn)確一些， 而且它的復(fù)雜度與業(yè)務(wù)方的預(yù)估不會(huì)差太多。

常見的DDD誤區(qū)：

DDD一定要用微服務(wù)？不，其實(shí)多個(gè)域在同一個(gè)進(jìn)程也沒問題，只要滿足一個(gè)聚合在一個(gè)事務(wù)內(nèi)保護(hù)就沒有問題。

DDD的架構(gòu)是穩(wěn)定的？這么問的人一定沒有理解什么叫做領(lǐng)域驅(qū)動(dòng)。當(dāng)領(lǐng)域發(fā)生演化的時(shí)候，系統(tǒng)的改變肯定不會(huì)小。比如電商系統(tǒng)里收貨地址，可能一開始只是沒有業(yè)務(wù)意義的值對(duì)象，但是后續(xù)有了管理，比如家庭，公司，然后反過來(lái)繪制畫像，精準(zhǔn)推薦……地址有了管理系統(tǒng)，那就不再是值對(duì)象了。

但是DDD能保證在每期迭代中，需要做的工作都是最貼合當(dāng)前需求的，并且當(dāng)下一迭代到來(lái)的時(shí)候，做的改造工作量也是各方可以理解的。與之相反的所謂提前規(guī)劃，通常會(huì)演化為把之后若干迭代的部分放到當(dāng)前迭代，而且當(dāng)未來(lái)沒有按照預(yù)定的方式改變時(shí)，這些工作可能還是無(wú)效的。

審核編輯：劉清