前言

接一年多前的上篇（小團(tuán)隊(duì)也能做DDD），上篇主要講了為什么，這篇核心講下怎么做。從上篇的分析可以看出領(lǐng)域模型是一個(gè)核心產(chǎn)出物，有了領(lǐng)域模型，限界上下文和代碼模型就可以產(chǎn)出，最終落地到微服務(wù)和具體的代碼。本文先介紹業(yè)務(wù)系統(tǒng)的核心元素，再講產(chǎn)出領(lǐng)域模型的一個(gè)方法：兩圖兩表法，最后做個(gè)總結(jié)。

業(yè)務(wù)系統(tǒng)的核心元素

在講怎么產(chǎn)出領(lǐng)域模型之前，回顧下一個(gè)業(yè)務(wù)系統(tǒng)最重要的東西是什么，先看1個(gè)公式：

計(jì)算機(jī)程序=算法+數(shù)據(jù)結(jié)構(gòu)

這個(gè)公式是大學(xué)課本里見到過，是圖靈獎(jiǎng)得主:尼古拉斯·沃斯提出的，那我們平常做得多的軟件是業(yè)務(wù)系統(tǒng)，看起來也沒什么算法，數(shù)據(jù)結(jié)構(gòu)用List,Map之外也沒用過多么高大上的東西，明顯不太符合大師的這個(gè)公式。我們換個(gè)思路，先做類比，把程序當(dāng)作一個(gè)人的話，數(shù)據(jù)結(jié)構(gòu)是心肝脾肺腎各種器官，相對(duì)靜態(tài)不動(dòng)；算法是血液，動(dòng)態(tài)輸送到器官，影響器官。從這個(gè)角度看業(yè)務(wù)系統(tǒng)的血液是業(yè)務(wù)流程，器官是領(lǐng)域模型，業(yè)務(wù)流程代表業(yè)務(wù)流轉(zhuǎn)過程，這個(gè)過程中操作領(lǐng)域模型，所以我們得出如下一個(gè)公式：

業(yè)務(wù)系統(tǒng)=業(yè)務(wù)流程+領(lǐng)域模型

這個(gè)公式是上一個(gè)公式的變種，能較好的描述業(yè)務(wù)系統(tǒng)，可以說是業(yè)務(wù)系統(tǒng)的結(jié)構(gòu)化表達(dá)，為了梳理出業(yè)務(wù)系統(tǒng)的這兩個(gè)核心元素，我們講下一個(gè)領(lǐng)域建模的兩圖兩表法，這個(gè)方法相對(duì)比較簡(jiǎn)單，也好操作，方便落地。

兩圖兩表法

這個(gè)方法是自己的一個(gè)總結(jié)，學(xué)習(xí)了不少專家的文章和書籍，先看定義：

為了避免扯皮，上面表格里面給了4個(gè)產(chǎn)出物由什么角色產(chǎn)出合適。由于業(yè)務(wù)術(shù)語，業(yè)務(wù)流程偏向需求分析，所以由需求分析人員產(chǎn)出相對(duì)合理，角色目標(biāo)實(shí)體表需要兩個(gè)角色一起產(chǎn)出，領(lǐng)域模型圖雖然說也是可以由需求分析人員產(chǎn)出，但這里畢竟跟代碼模型牽扯比較緊密，我建議是業(yè)務(wù)系統(tǒng)架構(gòu)師產(chǎn)出，再跟需求分析人員和領(lǐng)域?qū)＜疫_(dá)成一致，也可以根據(jù)團(tuán)隊(duì)成員的情況來，有些需求分析人員對(duì)軟件抽象掌握比較好，產(chǎn)出領(lǐng)域模型也是可以的。

詳細(xì)步驟如下：

接下來針對(duì)每個(gè)產(chǎn)出物做解釋。

業(yè)務(wù)術(shù)語表

目的是統(tǒng)一語言，減少溝通障礙，簡(jiǎn)單說就是名詞解釋，如果一個(gè)術(shù)語比較復(fù)雜，要用why,what,how來解釋清楚，這三個(gè)東西不是每個(gè)術(shù)語都得寫，要看某一項(xiàng)是否明確，比如what非常清楚，就可以省略。特別強(qiáng)調(diào)的是我們經(jīng)常忘記寫為什么，導(dǎo)致業(yè)務(wù)術(shù)語看不懂

業(yè)務(wù)術(shù)語表的一個(gè)簡(jiǎn)單模板如下：

業(yè)務(wù)流程圖

業(yè)務(wù)流程能描述業(yè)務(wù)整體流轉(zhuǎn)過程，串起業(yè)務(wù)活動(dòng)，是數(shù)字化起點(diǎn)。流程圖分為兩類：業(yè)務(wù)流程（以人為基礎(chǔ)），系統(tǒng)流程（以物為基礎(chǔ)）。這兩個(gè)流程圖的出發(fā)點(diǎn)不一樣，是先有業(yè)務(wù)流程再有系統(tǒng)流程，兩者不可混淆在一起。流程圖常用的展現(xiàn)形式是泳道圖，對(duì)于業(yè)務(wù)流程，因?yàn)槭且匀藶榛A(chǔ)，那么每條泳道代表一個(gè)業(yè)務(wù)角色。

流程圖有一個(gè)難點(diǎn)在于粒度，對(duì)于DDD而言，已經(jīng)到了一個(gè)具體問題域的業(yè)務(wù)分析，這個(gè)需要落地到需求開發(fā)，流程圖粒度直接到具體的業(yè)務(wù)角色需要干什么事情，才能有效的指導(dǎo)開發(fā)。多提一句，企業(yè)架構(gòu)里面對(duì)流程有個(gè)PCF流程分級(jí)方法，我們這里提到的具體流程算是L3級(jí)流程。拿中國地圖舉例說明下流程分級(jí)，L1級(jí)流程是一個(gè)國家省的劃分，L2級(jí)流程是對(duì)某個(gè)省做城市的劃分，L3級(jí)流程是對(duì)城市做鄉(xiāng)鎮(zhèn)的劃分。可以看到高階抽象的流程是為了看范圍更大，更復(fù)雜的企業(yè)級(jí)的業(yè)務(wù)過程，這屬于企業(yè)架構(gòu)內(nèi)容，感興趣的同學(xué)可以學(xué)習(xí)這塊，企業(yè)架構(gòu)+DDD非常配。

下圖是一個(gè)員工請(qǐng)假的業(yè)務(wù)流程圖：

角色目標(biāo)實(shí)體表

角色目標(biāo)實(shí)體表是為了梳理業(yè)務(wù)實(shí)體，我們的業(yè)務(wù)流程跟業(yè)務(wù)實(shí)體到底怎么關(guān)聯(lián)起來，業(yè)務(wù)實(shí)體不是憑空產(chǎn)生的，就是通過這個(gè)角色目標(biāo)實(shí)體表，這個(gè)方法從Thoughtworks徐昊的文章里面提到過,我覺得比事件風(fēng)暴要容易學(xué)習(xí)和落地，畢竟學(xué)得會(huì)的方法才是好方法。具體方法是把業(yè)務(wù)角色全部列出來，然后順著業(yè)務(wù)流程，梳理出用例，過程中出現(xiàn)的名詞，就是涉及的實(shí)體。看例子：

上表是個(gè)非常簡(jiǎn)單的場(chǎng)景，企業(yè)的業(yè)務(wù)遠(yuǎn)比這個(gè)要復(fù)雜，僅僅用來說明角色目標(biāo)實(shí)體表的形態(tài)，可以看到這個(gè)表相當(dāng)于把用例和實(shí)體結(jié)合起來。

領(lǐng)域模型圖

領(lǐng)域模型圖是本文的最終目標(biāo)，是軟件的骨架。角色目標(biāo)實(shí)體表產(chǎn)出的實(shí)體，用UML圖表達(dá)出來，就形成了領(lǐng)域模型圖。實(shí)體和實(shí)體的關(guān)系大體有3種：繼承，聚合，關(guān)聯(lián)。下圖是一個(gè)例子：

具體可以參考如下步驟：

把角色目標(biāo)實(shí)體表的所有實(shí)體畫出來

根據(jù)繼承，聚合，關(guān)聯(lián)3種關(guān)系對(duì)實(shí)體進(jìn)行連線，聚合可以用一個(gè)虛線框框出來

多個(gè)聚合組合成限界上下文

團(tuán)隊(duì)共識(shí)消化，對(duì)于缺少的實(shí)體進(jìn)行補(bǔ)充等

這個(gè)步驟的難點(diǎn)在于第4步，怎么合理的劃分出限界上下文。要做到劃分后的限界上下文之間的接口最少，這個(gè)最優(yōu)解肯定存在，但比較依賴經(jīng)驗(yàn)，有經(jīng)驗(yàn)的架構(gòu)師深刻理解高內(nèi)聚低耦合，一把到位。怎么劃分這里也給出一些建議：

根據(jù)子域來識(shí)別限界上下文，那么子域如何得到呢？我們通過分解問題域的方式，將整個(gè)問題域分解成若干個(gè)更小、更簡(jiǎn)單、更容易解決的問題子域。

一個(gè)限界上下文邊界內(nèi)，實(shí)體的含義是不存在二義性的。如果存在兩個(gè)人對(duì)一個(gè)實(shí)體理解不同，那這個(gè)實(shí)體說明有二義性，很可能是這個(gè)實(shí)體要分離成兩個(gè)實(shí)體，放到不同的限界上下文。舉個(gè)例子，商品管理，銷售訂單，發(fā)貨三個(gè)業(yè)務(wù)都有商品的概念，表面看好像是同一個(gè)實(shí)體，深入分析實(shí)際是不同的實(shí)體，銷售訂單里面商品其實(shí)是訂單項(xiàng)，發(fā)貨業(yè)務(wù)的商品關(guān)注的是大小，重量等，實(shí)際上是貨品，所以這里是三個(gè)不同的限界上下文，每個(gè)限界上下文里面都有一個(gè)“商品”實(shí)體，命名上要區(qū)分開。

限界上下文分不清就先別分了，減少扯皮，團(tuán)隊(duì)內(nèi)共識(shí)后，迭代演進(jìn)。

領(lǐng)域模型圖產(chǎn)出后，需要拉上領(lǐng)域?qū)＜乙黄鸸沧R(shí)，當(dāng)然很多團(tuán)隊(duì)要做到這個(gè)不現(xiàn)實(shí)，那就盡最大范圍去共識(shí)，形成統(tǒng)一語言。接下來領(lǐng)域模型就可以給代碼開發(fā)提供輸入了，我們可以把梳理的領(lǐng)域模型都放到一個(gè)單體系統(tǒng)來實(shí)現(xiàn)，每個(gè)限界上下文是一個(gè)package，這個(gè)是最簡(jiǎn)單的，如果實(shí)在要做微服務(wù)拆分，限界上下文這個(gè)業(yè)務(wù)邊界也是優(yōu)先考慮的，除此以外還要綜合考慮彈性邊界，組織架構(gòu)等問題了，這個(gè)屬于微服務(wù)拆分的話題了。

總結(jié)

業(yè)務(wù)流程和領(lǐng)域模型構(gòu)成業(yè)務(wù)系統(tǒng)的核心要素，業(yè)務(wù)流程升級(jí)到業(yè)務(wù)價(jià)值流，領(lǐng)域模型升級(jí)到企業(yè)級(jí)業(yè)務(wù)對(duì)象，這就變成了企業(yè)架構(gòu)的方法（價(jià)值流+業(yè)務(wù)能力+業(yè)務(wù)對(duì)象），所以DDD和企業(yè)架構(gòu)方法是相通的，一個(gè)是微觀，一個(gè)是宏觀，兩者結(jié)合可以更好的認(rèn)識(shí)數(shù)字化建設(shè)。最后預(yù)告下篇內(nèi)容，上代碼模型。

審核編輯：劉清