前言

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

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

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

計算機程序=算法+數(shù)據(jù)結構

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

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

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

兩圖兩表法

這個方法是自己的一個總結，學習了不少專家的文章和書籍，先看定義：

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

詳細步驟如下：

接下來針對每個產出物做解釋。

業(yè)務術語表

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

業(yè)務術語表的一個簡單模板如下：

業(yè)務流程圖

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

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

下圖是一個員工請假的業(yè)務流程圖：

角色目標實體表

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

上表是個非常簡單的場景，企業(yè)的業(yè)務遠比這個要復雜，僅僅用來說明角色目標實體表的形態(tài)，可以看到這個表相當于把用例和實體結合起來。

領域模型圖

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

具體可以參考如下步驟：

把角色目標實體表的所有實體畫出來

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

多個聚合組合成限界上下文

團隊共識消化，對于缺少的實體進行補充等

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

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

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

限界上下文分不清就先別分了，減少扯皮，團隊內共識后，迭代演進。

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

總結

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

審核編輯：劉清