為什么需要DDD？

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

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

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

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

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

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

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

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

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

DDD是什么呢?

我們先看幾個*DD：

TDD 驅(qū)動測試開發(fā)

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

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

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

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

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

那么怎么做DDD呢?

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

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

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

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

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

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

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

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

使用上下文映射來集成多個限界上下文

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

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

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

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

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

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

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

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

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

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

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

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

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

使用上下文映射來集成多個限界上下文

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

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

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

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

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

把一些實體和值對象放一起，稱為聚合。

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

聚合怎么設(shè)計

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

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

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

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

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

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

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

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

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

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

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

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

事件風(fēng)暴

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

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

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

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

各種顏色便利貼，正方形的。一般一個便利貼只會寫幾個詞。

每個人都有黑色的馬克筆。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一個命令可以帶來多個事件

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

在建模平面上畫出邊界和事件流動的箭頭。

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

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

時間評估工具

時間評估工具是如下的一個經(jīng)驗表格：

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

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

常見的DDD誤區(qū)：

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

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

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

審核編輯：劉清