編輯導(dǎo)語：DDD（Domain-driven design，領(lǐng)域驅(qū)動設(shè)計）是一種架構(gòu)設(shè)計方法論，通過邊界劃分，將復(fù)雜業(yè)務(wù)領(lǐng)域簡單化，幫助我們設(shè)計出清晰的領(lǐng)域和應(yīng)用邊界，保證業(yè)務(wù)模型與代碼模型的一致性。本文作者結(jié)合實(shí)際經(jīng)驗，介紹了如何從0到1實(shí)踐DDD，一起來看看吧。

隨著業(yè)務(wù)的不斷發(fā)展，我們發(fā)現(xiàn)自己的系統(tǒng)開始變得有點(diǎn)臃腫，為了減少復(fù)雜性，我們嘗試借助DDD來改善我們的系統(tǒng)。本文記錄了自己對DDD的理解和實(shí)踐過程，歡迎大家一起探討。見識所限，難免有理解不到位，希望路過的大佬不吝賜教。

一、為什么需要DDD

• 當(dāng)朋友和你聊工作時，你能否一語中的，說清你在開發(fā)中的業(yè)務(wù)內(nèi)容及其價值？
• 當(dāng)產(chǎn)品和你聊需求時，你是否遇到過反復(fù)溝通之后才發(fā)現(xiàn)講的不是同個東西的情況？
• 當(dāng)你在做需求評估時，你是否經(jīng)常發(fā)現(xiàn)一個小的需求改動，總是牽一發(fā)動全身？
• 當(dāng)你在快樂寫代碼時，你是否經(jīng)常覺得有些類可有可無，有些接口望文不知義？

如果你有以上的一些疑問，那你可以試試領(lǐng)域驅(qū)動設(shè)計：

DDD（Domain-driven design，領(lǐng)域驅(qū)動設(shè)計）是一種架構(gòu)設(shè)計方法論，通過邊界劃分，將復(fù)雜業(yè)務(wù)領(lǐng)域簡單化，幫助我們設(shè)計出清晰的領(lǐng)域和應(yīng)用邊界，保證業(yè)務(wù)模型與代碼模型的一致性。

在細(xì)看這個定義之前，我們可以思考一下，為什么我們的業(yè)務(wù)系統(tǒng)會慢慢變得復(fù)雜？

常見的情況是，業(yè)務(wù)在發(fā)展過程中為了探尋發(fā)力點(diǎn)，需要不斷地試錯迭代，調(diào)整方向，而系統(tǒng)在設(shè)計之初，難以預(yù)期到后面的瞬息萬變，為了應(yīng)付業(yè)務(wù)，修修改改，久之，系統(tǒng)也變得復(fù)雜起來。

可以怎么辦呢？及時重構(gòu)唄——不改變軟件系統(tǒng)外部行為的前提下，改善它的內(nèi)部結(jié)構(gòu)。

然而重構(gòu)是從技術(shù)層面上抽煉出來的模型，往往不具有實(shí)際的業(yè)務(wù)含義，其他同學(xué)可能難以自然地將業(yè)務(wù)問題映射到對應(yīng)的設(shè)計模型。另外，如果不能如實(shí)映射業(yè)務(wù)模型，隨著業(yè)務(wù)方向調(diào)整，代碼可能又開始腐敗……有點(diǎn)像芝諾悖論中，阿基里斯永遠(yuǎn)追不上小烏龜。

那DDD怎么搞？

DDD是這么想的：”將業(yè)務(wù)架構(gòu)映射到系統(tǒng)架構(gòu)上，在響應(yīng)業(yè)務(wù)變化調(diào)整業(yè)務(wù)架構(gòu)時，也隨之變化系統(tǒng)架構(gòu)”?？赡艽蠹移綍r有這樣的想法，但是比較模糊，未形成體系，而DDD就提供了一套完整的方法論。從業(yè)務(wù)角度去審視我們的系統(tǒng)，從而實(shí)現(xiàn)高內(nèi)聚低耦合的代碼。

整體而言，領(lǐng)域驅(qū)動設(shè)計包括戰(zhàn)略建模和戰(zhàn)術(shù)建模: 戰(zhàn)略設(shè)計側(cè)重于高層次、宏觀上去劃分和集成限界上下文，而戰(zhàn)術(shù)設(shè)計則關(guān)注更具體使用建模工具來細(xì)化上下文。

二、 如何實(shí)現(xiàn)DDD之戰(zhàn)略建模

1. 基本概念

1）領(lǐng)域、子域

在討論問題之前，我們需要先定義好問題。

領(lǐng)域即問題域，通常是根據(jù)一個組織所處的行業(yè)進(jìn)行識別，它基于業(yè)務(wù)的愿景，定義了系統(tǒng)要解決的現(xiàn)實(shí)問題的目標(biāo)和范圍。領(lǐng)域越大，業(yè)務(wù)的范圍也越大，大的領(lǐng)域可以拆分成小的問題域，稱之為子域。根據(jù)子域重要性和功能屬性劃，可以將其分為三類。

核心域、支撐域和通用域：

• 核心域：決定產(chǎn)品核心競爭力的子域
• 支撐域：實(shí)現(xiàn)核心域目標(biāo)所需的，但重要程度不如核心域的子域，一般具備強(qiáng)烈的個性化需求
• 通用域：具有通用功能，可被多個子域使用的的是通用域。該子域所解決的問題一般是業(yè)界常見問題，有成熟的解決方案，可直接購買或簡單修改來使用

這個幾個概念其實(shí)很容易理解，不過在劃分的時候，注意要從業(yè)務(wù)的視角，而不是技術(shù)功能模塊來劃分。

2）限界上下文

我們語言博大精深，同樣的話在不同語境下就可演變出不同含義，這在溝通時總是帶來不必要的麻煩。為了準(zhǔn)確地溝通，我們需要統(tǒng)一語言的邊界，在相同的語言邊界內(nèi)溝通，才不容易出差錯。

一則阿凡提當(dāng)理發(fā)師懲罰一個狡猾牧師的趣事：理發(fā)時，阿凡提刮臉時問牧師：“牧師,是否要眉毛?”牧師答：“這還用問,眉毛豈能不要?”.“好，你要我就給你！”，說著就把牧師的眉毛刮下來遞到他手里，牧師氣得說不出話來，誰叫自己說要呢。阿凡提又問：“牧師,胡子要嗎?”.“不要，不要！”牧師連忙說?！昂?，你不要就不要。” 嗖嗖幾刀就把牧師的胡子刮下來。

在一個系統(tǒng)中，一個名詞在不同語境可能有不同的含義，我們對它關(guān)注的屬性和行為也有所不同。例如，在電商系統(tǒng)中，對于產(chǎn)品Product， 在采購上下文，需要關(guān)注產(chǎn)品的進(jìn)價、最小起訂量與供貨周期；在市場上下文中，則關(guān)心產(chǎn)品的品質(zhì)、售價，以及用于促銷的精美圖片和銷售類型；在倉儲上下文中，倉庫工作人員更關(guān)心產(chǎn)品放在倉庫的哪個位置，產(chǎn)品的重量與體積，是否易碎品以及訂購產(chǎn)品的數(shù)量。

限界上下文在《實(shí)現(xiàn)領(lǐng)域驅(qū)動設(shè)計》中，用了很大篇幅去講，它有幾個重要的意義：

1. 限界上下文是領(lǐng)域概念的語言邊界與業(yè)務(wù)邊界：在這個邊界內(nèi)，領(lǐng)域概念的內(nèi)涵是清晰、無歧義的
2. 限界上下文是團(tuán)隊的工作邊界：組織邊界與限界上下文對齊
3. 限界上下文是技術(shù)方案的實(shí)施邊界：在這個邊界內(nèi)，技術(shù)方案是獨(dú)立自治的，業(yè)務(wù)邏輯不會落入不同技術(shù)邊界的間隙

經(jīng)過戰(zhàn)略建模之后，我們可以得到以下的一個模型：

2. 業(yè)務(wù)實(shí)踐

為了更好地理解，我們對手上的一個項目：“IoT設(shè)備增值產(chǎn)品管理系統(tǒng)”進(jìn)行實(shí)踐。該項目中，我們提供給商戶在IoT設(shè)備上管理增值運(yùn)營產(chǎn)品的能力。這里的IoT設(shè)備主要是微信支付刷臉設(shè)備等。商戶可以在系統(tǒng)中創(chuàng)建我們業(yè)務(wù)中的增值運(yùn)營產(chǎn)品，如電子海報、互動海報等，創(chuàng)建完之后，相關(guān)的增值產(chǎn)品會被投放到IoT設(shè)備上，進(jìn)行展示、運(yùn)作：

一開始我們從業(yè)務(wù)的用例出發(fā)，認(rèn)為我們的系統(tǒng)主要是商戶在我們頁面網(wǎng)站使用，以及IoT設(shè)備通過接口連接我們后臺服務(wù)，認(rèn)為這兩個分屬不同的子域，然后梳理了一些支撐的功能：

畫完草圖之后，感覺不是很確定，于是便去咨詢部門的DDD專家王老師（十分感謝王立老師的指導(dǎo)），得到了一些寶貴的建議：我們應(yīng)該避免直接從表現(xiàn)層去看業(yè)務(wù)，表現(xiàn)層就像是冰山露在水面上的棱角，這些棱角看起來毫不相干，但是實(shí)際上底層是連成一塊的，這些才是我們需要關(guān)注的。

就像這個項目，表面上商戶和設(shè)備是分開的，實(shí)際上它們在操作都是我們的增值運(yùn)營產(chǎn)品，應(yīng)該看成我們的系統(tǒng)提供統(tǒng)一對外的服務(wù)，然后商戶和設(shè)備來使用我們的服務(wù)。UGC內(nèi)容存儲業(yè)務(wù)用例其實(shí)沒有涉及到的，屬于實(shí)現(xiàn)時候的東西。一番建議讓我們理清了思路，于是重新梳理，得到以下的戰(zhàn)略建模圖：

整體而言，我們將整體系統(tǒng)梳理為8個子域：

1. 增值運(yùn)營服務(wù)子域：核心域，是我們業(yè)務(wù)主要競爭力。從業(yè)務(wù)上來講，我們的核心是通過提供業(yè)務(wù)中IoT設(shè)備上的增值運(yùn)營服務(wù)
2. 增值運(yùn)營產(chǎn)品子域：支撐域，這里主要是我們提供增值運(yùn)營產(chǎn)品，如電子海報、互動海報等
3. 生效場景子域：支撐域，業(yè)務(wù)中增值運(yùn)營產(chǎn)品有不同生效場景，這里統(tǒng)一進(jìn)行管理
4. 準(zhǔn)入子域：支撐域，現(xiàn)主要是業(yè)務(wù)中對使用者的一些限制規(guī)則
5. 權(quán)限管理子域：支撐域，基于角色來管理使用者的權(quán)限
6. 商戶信息子域：支撐域，提供商戶的信息
7. IoT設(shè)備信息子域：支撐域，提供IoT設(shè)備的信息
8. 風(fēng)險識別子域：通用域，識別業(yè)務(wù)中一些安全風(fēng)險，如不合規(guī)的UGC素材等。這部分是業(yè)界常見問題，可以使用通用方案來解決，實(shí)際上我們也是接入TEG的能力來實(shí)現(xiàn)

其中我們系統(tǒng)中的商戶信息依賴了微信支付商戶賬號信息和IoT設(shè)備鋪設(shè)服務(wù)信息，這里使用防腐層進(jìn)行隔離，將外部的商戶信息“翻譯”為我們業(yè)務(wù)中的商戶信息。三、如何實(shí)現(xiàn)DDD之戰(zhàn)術(shù)建模梳理清楚上下文之間的關(guān)系后，我們基本了解業(yè)務(wù)的概貌，接下來需要細(xì)化上下文，進(jìn)一步完善我們的模型。這里也需要用到DDD的一些基本概念。

3. 基本概念

1）實(shí)體、值對象

實(shí)體和值對象是組成領(lǐng)域模型的基礎(chǔ)單元。當(dāng)一個對象由其標(biāo)識（而不是屬性）區(qū)分時，這種對象稱為實(shí)體。如在校園教務(wù)系統(tǒng)中，每個賬戶是對應(yīng)著一個學(xué)生，根據(jù)學(xué)號來唯一標(biāo)識，可以認(rèn)為是一個實(shí)體。傳統(tǒng)的數(shù)據(jù)建模大多是根據(jù)數(shù)據(jù)庫范式設(shè)計的，每一個數(shù)據(jù)庫表對應(yīng)一個實(shí)體，每一個實(shí)體的屬性值用單獨(dú)的一列來存儲，一個實(shí)體主表會對應(yīng) N 個實(shí)體從表。

與其不同，DDD 是先構(gòu)建領(lǐng)域模型，再將業(yè)務(wù)對象映射為持久化對象。這可能導(dǎo)致DDD建立出來的實(shí)體，映射到具體數(shù)據(jù)庫表時，可能是1對多，多對1的關(guān)系。

如一個賬戶實(shí)體，有它的基本信息和權(quán)限角色信息，可能就對應(yīng)了2個持久化對象。另一方面，有時候為了某些查詢場景的方便，會把教師賬戶、學(xué)生賬戶等對應(yīng)成一個持久化對象，就成了多對1。

通過對象屬性值來識別的對象，則可以認(rèn)為是一個值對象。如地址信息{“省”: “廣東省”，”市”:”深圳市”}，我們是通過它的屬性來區(qū)分出不同的地址。值對象實(shí)際上是想把一些不變的屬性組合起來，減少系統(tǒng)的復(fù)雜性。在設(shè)計值對象的時候，需要滿足以下的特性：

1. 值對象相等性：可以通過對其屬性的比較，來區(qū)分不同的值對象
2. 不變性：需要保證值對象創(chuàng)建后就不能被修改，即不允許外部再修改其屬性
3. 可替換性：值對象是一個整體，當(dāng)其描述的對象有變化時，需要用一個新的值對象來替換對于值對象，由于其具有不變性，且是通過屬性來判斷相等的，在設(shè)計對應(yīng)的數(shù)據(jù)庫持久化對象時，可以將其以JSON形式存儲在數(shù)據(jù)庫表的某一字段中

2）聚合、聚合根

在 DDD 中，實(shí)體和值對象是基礎(chǔ)的領(lǐng)域?qū)ο?。?shí)體一般對應(yīng)業(yè)務(wù)對象，它具有業(yè)務(wù)屬性和業(yè)務(wù)行為；而值對象主要是屬性集合，對實(shí)體的狀態(tài)和特征進(jìn)行描述。但是我們的一個業(yè)務(wù)流程中，一般會同時涉及多個實(shí)體、值對象的操作，這里業(yè)務(wù)邏輯緊密的實(shí)體和值對象便組合成一個聚合。

從數(shù)據(jù)層面來看，同個聚合內(nèi)的數(shù)據(jù)需要保持強(qiáng)一致性。

每一個聚合有一個聚合根實(shí)體，設(shè)置聚合根的主要目的是為了避免由于復(fù)雜數(shù)據(jù)模型缺少統(tǒng)一的業(yè)務(wù)規(guī)則控制，而導(dǎo)致聚合、實(shí)體之間數(shù)據(jù)不一致性的問題。聚合根可以看成是聚合的管理者，或是說handle。對內(nèi)其協(xié)調(diào)實(shí)體和值對象完成業(yè)務(wù)邏輯。對外則提供通過聚合ID供其他聚合關(guān)聯(lián)引用，屏蔽外部對內(nèi)部實(shí)體的直接訪問和修改。

建議的聚合設(shè)計原則：

1. 在一致性邊界之內(nèi)確保不變性：聚合用來封裝真正的不變性，而不是簡單地將對象組合在一起。聚合內(nèi)有一套不變的業(yè)務(wù)規(guī)則，各實(shí)體和值對象按照統(tǒng)一的業(yè)務(wù)規(guī)則運(yùn)行，實(shí)現(xiàn)對象數(shù)據(jù)的一致性。
2. 設(shè)計小聚合：如果聚合聚合包含過多的實(shí)體，會提高管理實(shí)體的復(fù)雜性，高頻操作下容易并發(fā)沖突，降低了系統(tǒng)的性能。
3. 在邊界之外使用最終一致性：不同的聚合之間不要求強(qiáng)一致性，保證最終一致性。一次事務(wù)操作中，只修改一個聚合實(shí)例，如果需要修改多個實(shí)例，可以考慮通過異步的方式保證最終一致性。

3）領(lǐng)域服務(wù)

領(lǐng)域服務(wù)的定義：領(lǐng)域中的服務(wù)表示一個無狀態(tài)的操作，它用于實(shí)現(xiàn)特定于某個領(lǐng)域的任務(wù)。當(dāng)某個操作不適合放在聚合（實(shí)體）或值對像上時，最好的方式便是使用領(lǐng)域服務(wù)。

舉個例子，在一個路線導(dǎo)航的項目中，“路線”可能是其中的一個實(shí)體，如果業(yè)務(wù)中有“推薦路線上相關(guān)的美食”這樣一個功能，那我們會想，這個功能應(yīng)該歸給哪個領(lǐng)域?qū)ο?，給“路線”實(shí)體嗎？有點(diǎn)不合適，應(yīng)該路線本身關(guān)注的是起終點(diǎn)，時間人物等。

此時可以將其這個功能歸為領(lǐng)域服務(wù)，它是一個路線狀態(tài)無關(guān)的服務(wù)，輸入路線各個節(jié)點(diǎn)，來得到沿路的各種美食。當(dāng)然，要注意不要過度地使用領(lǐng)域服務(wù)，因為這很可能導(dǎo)致你把實(shí)體的行為都放在里面了，實(shí)體本身都變成了一些只有g(shù)etter和setter的“貧血模型”。

4）領(lǐng)域事件

領(lǐng)域事件是領(lǐng)域模型中非常重要的一部分，用來表示領(lǐng)域中發(fā)生的事件。一個領(lǐng)域事件將導(dǎo)致進(jìn)一步的業(yè)務(wù)操作，在實(shí)現(xiàn)業(yè)務(wù)解耦的同時，還有助于形成完整的業(yè)務(wù)閉環(huán)。

領(lǐng)域事件含義很廣泛，可以是業(yè)務(wù)流程的一個步驟，也可以是一個事件發(fā)生后觸發(fā)的后續(xù)動作，繳費(fèi)完成之后，觸發(fā)短信通知；上面在設(shè)計聚合的時候，我們提到一個原則：在邊界之外使用最終一致性，一次事務(wù)最多只能更改一個聚合的狀態(tài)。如果一次業(yè)務(wù)操作涉及多個聚合狀態(tài)的更改，應(yīng)通過領(lǐng)域事件，達(dá)到最終一致性。

實(shí)際上是通過事件驅(qū)動的這種異步方式，對系統(tǒng)進(jìn)行解耦。當(dāng)然，如果你覺得某兩個步驟，業(yè)務(wù)流程上不允許是不一致的，那就得重新考慮將其歸在同個聚合中了。

4. 業(yè)務(wù)實(shí)踐

我們以增值運(yùn)營服務(wù)上下文為例，根據(jù)上面的理解，結(jié)合業(yè)務(wù)實(shí)際，得到以下模型：

其中增值產(chǎn)品是其中的一個聚合根，通過該聚合根進(jìn)行各種領(lǐng)域操作。海報縮略圖是其中的一個領(lǐng)域服務(wù)，通過輸入產(chǎn)品素材中的海報url，來得到一個海報的縮略圖。

四、工程實(shí)踐

傳統(tǒng)的三層架構(gòu)和DDD的分層結(jié)構(gòu)：

在《領(lǐng)域驅(qū)動設(shè)計——軟件核心復(fù)雜性的應(yīng)對之道》一書中，Eric提出了這樣的一種分層結(jié)構(gòu)，將整個系統(tǒng)劃分為四層：用戶接口層、應(yīng)用層、領(lǐng)域?qū)雍突A(chǔ)設(shè)施層。

用戶接口層：用戶接口層負(fù)責(zé)向用戶顯示信息和解釋用戶指令。

應(yīng)用層：應(yīng)用層相對來說是較“薄”的一層，主要是部署了應(yīng)用服務(wù)。應(yīng)用服務(wù)的實(shí)現(xiàn)中，它負(fù)責(zé)編排和轉(zhuǎn)發(fā)下一層的領(lǐng)域?qū)拥慕涌?，將要?shí)現(xiàn)的功能委托給一個或多個領(lǐng)域?qū)ο髞韺?shí)現(xiàn)，本身只負(fù)責(zé)處理業(yè)務(wù)用例的執(zhí)行順序以及結(jié)果的拼裝。

領(lǐng)域?qū)樱?/strong>領(lǐng)域?qū)邮潜容^“厚”的一層，它包含聚合根、實(shí)體、值對象、領(lǐng)域服務(wù)等領(lǐng)域模型中的領(lǐng)域?qū)ο?，?shí)現(xiàn)了核心的業(yè)務(wù)邏輯。領(lǐng)域?qū)雍蛻?yīng)用層的職責(zé)看起來有點(diǎn)模糊。