前言
接一年多前的上篇(小團(tuán)隊(duì)也能做DDD),上篇主要講了為什么,這篇核心講下怎么做。從上篇的分析可以看出領(lǐng)域模型是一個核心產(chǎn)出物,有了領(lǐng)域模型,限界上下文和代碼模型就可以產(chǎn)出,最終落地到微服務(wù)和具體的代碼。本文先介紹業(yè)務(wù)系統(tǒng)的核心元素,再講產(chǎn)出領(lǐng)域模型的一個方法:兩圖兩表法,最后做個總結(jié)。
業(yè)務(wù)系統(tǒng)的核心元素
在講怎么產(chǎn)出領(lǐng)域模型之前,回顧下一個業(yè)務(wù)系統(tǒng)最重要的東西是什么,先看1個公式:
計(jì)算機(jī)程序=算法+數(shù)據(jù)結(jié)構(gòu)
這個公式是大學(xué)課本里見到過,是圖靈獎得主:尼古拉斯·沃斯提出的,那我們平常做得多的軟件是業(yè)務(wù)系統(tǒng),看起來也沒什么算法,數(shù)據(jù)結(jié)構(gòu)用List,Map之外也沒用過多么高大上的東西,明顯不太符合大師的這個公式。我們換個思路,先做類比,把程序當(dāng)作一個人的話,數(shù)據(jù)結(jié)構(gòu)是心肝脾肺腎各種器官,相對靜態(tài)不動;算法是血液,動態(tài)輸送到器官,影響器官。從這個角度看業(yè)務(wù)系統(tǒng)的血液是業(yè)務(wù)流程,器官是領(lǐng)域模型,業(yè)務(wù)流程代表業(yè)務(wù)流轉(zhuǎn)過程,這個過程中操作領(lǐng)域模型,所以我們得出如下一個公式:
業(yè)務(wù)系統(tǒng)=業(yè)務(wù)流程+領(lǐng)域模型
這個公式是上一個公式的變種,能較好的描述業(yè)務(wù)系統(tǒng),可以說是業(yè)務(wù)系統(tǒng)的結(jié)構(gòu)化表達(dá),為了梳理出業(yè)務(wù)系統(tǒng)的這兩個核心元素,我們講下一個領(lǐng)域建模的兩圖兩表法,這個方法相對比較簡單,也好操作,方便落地。
兩圖兩表法
這個方法是自己的一個總結(jié),學(xué)習(xí)了不少專家的文章和書籍,先看定義:
目的 | 誰產(chǎn)出 | |
---|---|---|
業(yè)務(wù)術(shù)語表 | 統(tǒng)一語言,去歧義 | 需求分析人員 |
業(yè)務(wù)流程圖 | 梳理流程,觀大局 | 需求分析人員 |
角色目標(biāo)實(shí)體表 | 用例整理,列實(shí)體 | 需求分析人員或者架構(gòu)師 |
領(lǐng)域模型圖 | 實(shí)體建模,畫結(jié)構(gòu) | 業(yè)務(wù)系統(tǒng)架構(gòu)師 |
為了避免扯皮,上面表格里面給了4個產(chǎn)出物由什么角色產(chǎn)出合適。由于業(yè)務(wù)術(shù)語,業(yè)務(wù)流程偏向需求分析,所以由需求分析人員產(chǎn)出相對合理,角色目標(biāo)實(shí)體表需要兩個角色一起產(chǎn)出,領(lǐng)域模型圖雖然說也是可以由需求分析人員產(chǎn)出,但這里畢竟跟代碼模型牽扯比較緊密,我建議是業(yè)務(wù)系統(tǒng)架構(gòu)師產(chǎn)出,再跟需求分析人員和領(lǐng)域?qū)<疫_(dá)成一致,也可以根據(jù)團(tuán)隊(duì)成員的情況來,有些需求分析人員對軟件抽象掌握比較好,產(chǎn)出領(lǐng)域模型也是可以的。
詳細(xì)步驟如下:
接下來針對每個產(chǎn)出物做解釋。
業(yè)務(wù)術(shù)語表
目的是統(tǒng)一語言,減少溝通障礙,簡單說就是名詞解釋,如果一個術(shù)語比較復(fù)雜,要用why,what,how來解釋清楚,這三個東西不是每個術(shù)語都得寫,要看某一項(xiàng)是否明確,比如what非常清楚,就可以省略。特別強(qiáng)調(diào)的是我們經(jīng)常忘記寫為什么,導(dǎo)致業(yè)務(wù)術(shù)語看不懂
業(yè)務(wù)術(shù)語表的一個簡單模板如下:
術(shù)語 / 縮略詞 | 英文 | 說明 |
---|---|---|
XXX | XXX | XXX (為什么,是什么,怎么做), |
購物車 | Shopping Cart | 用戶瀏覽很多商品時,方便用戶暫存感興趣的商品,通過加入購物車完成商品的暫存 |
業(yè)務(wù)流程圖
業(yè)務(wù)流程能描述業(yè)務(wù)整體流轉(zhuǎn)過程,串起業(yè)務(wù)活動,是數(shù)字化起點(diǎn)。流程圖分為兩類:業(yè)務(wù)流程(以人為基礎(chǔ)),系統(tǒng)流程(以物為基礎(chǔ))。這兩個流程圖的出發(fā)點(diǎn)不一樣,是先有業(yè)務(wù)流程再有系統(tǒng)流程,兩者不可混淆在一起。流程圖常用的展現(xiàn)形式是泳道圖,對于業(yè)務(wù)流程,因?yàn)槭且匀藶榛A(chǔ),那么每條泳道代表一個業(yè)務(wù)角色。
流程圖有一個難點(diǎn)在于粒度,對于DDD而言,已經(jīng)到了一個具體問題域的業(yè)務(wù)分析,這個需要落地到需求開發(fā),流程圖粒度直接到具體的業(yè)務(wù)角色需要干什么事情,才能有效的指導(dǎo)開發(fā)。多提一句,企業(yè)架構(gòu)里面對流程有個PCF流程分級方法,我們這里提到的具體流程算是L3級流程。拿中國地圖舉例說明下流程分級,L1級流程是一個國家省的劃分,L2級流程是對某個省做城市的劃分,L3級流程是對城市做鄉(xiāng)鎮(zhèn)的劃分。可以看到高階抽象的流程是為了看范圍更大,更復(fù)雜的企業(yè)級的業(yè)務(wù)過程,這屬于企業(yè)架構(gòu)內(nèi)容,感興趣的同學(xué)可以學(xué)習(xí)這塊,企業(yè)架構(gòu)+DDD非常配。
下圖是一個員工請假的業(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)生的,就是通過這個角色目標(biāo)實(shí)體表,這個方法從Thoughtworks徐昊的文章里面提到過,我覺得比事件風(fēng)暴要容易學(xué)習(xí)和落地,畢竟學(xué)得會的方法才是好方法。具體方法是把業(yè)務(wù)角色全部列出來,然后順著業(yè)務(wù)流程,梳理出用例,過程中出現(xiàn)的名詞,就是涉及的實(shí)體。看例子:
角色 | 目標(biāo) | 干啥(XX地方做XX動作) | 實(shí)體 |
---|---|---|---|
員工 | 請假獲得批準(zhǔn) | HR系統(tǒng)或者郵件發(fā)起申請 | 請假單 |
上級 | 審批員工的請假 | 根據(jù)員工的假期進(jìn)行請假審批 | 請假單,員工,員工假期 |
HR | 維護(hù)好員工的假期 | 郵件類申請?jiān)贖R系統(tǒng)做好員工的假期備案,留下變更記錄 | 員工,員工假期,假期變更記錄 |
上表是個非常簡單的場景,企業(yè)的業(yè)務(wù)遠(yuǎn)比這個要復(fù)雜,僅僅用來說明角色目標(biāo)實(shí)體表的形態(tài),可以看到這個表相當(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)。下圖是一個例子:
具體可以參考如下步驟:
把角色目標(biāo)實(shí)體表的所有實(shí)體畫出來
根據(jù)繼承,聚合,關(guān)聯(lián)3種關(guān)系對實(shí)體進(jìn)行連線,聚合可以用一個虛線框框出來
多個聚合組合成限界上下文
團(tuán)隊(duì)共識消化,對于缺少的實(shí)體進(jìn)行補(bǔ)充等
這個步驟的難點(diǎn)在于第4步,怎么合理的劃分出限界上下文。要做到劃分后的限界上下文之間的接口最少,這個最優(yōu)解肯定存在,但比較依賴經(jīng)驗(yàn),有經(jīng)驗(yàn)的架構(gòu)師深刻理解高內(nèi)聚低耦合,一把到位。怎么劃分這里也給出一些建議:
根據(jù)子域來識別限界上下文,那么子域如何得到呢?我們通過分解問題域的方式,將整個問題域分解成若干個更小、更簡單、更容易解決的問題子域。
一個限界上下文邊界內(nèi),實(shí)體的含義是不存在二義性的。如果存在兩個人對一個實(shí)體理解不同,那這個實(shí)體說明有二義性,很可能是這個實(shí)體要分離成兩個實(shí)體,放到不同的限界上下文。舉個例子,商品管理,銷售訂單,發(fā)貨三個業(yè)務(wù)都有商品的概念,表面看好像是同一個實(shí)體,深入分析實(shí)際是不同的實(shí)體,銷售訂單里面商品其實(shí)是訂單項(xiàng),發(fā)貨業(yè)務(wù)的商品關(guān)注的是大小,重量等,實(shí)際上是貨品,所以這里是三個不同的限界上下文,每個限界上下文里面都有一個“商品”實(shí)體,命名上要區(qū)分開。
限界上下文分不清就先別分了,減少扯皮,團(tuán)隊(duì)內(nèi)共識后,迭代演進(jìn)。
領(lǐng)域模型圖產(chǎn)出后,需要拉上領(lǐng)域?qū)<乙黄鸸沧R,當(dāng)然很多團(tuán)隊(duì)要做到這個不現(xiàn)實(shí),那就盡最大范圍去共識,形成統(tǒng)一語言。接下來領(lǐng)域模型就可以給代碼開發(fā)提供輸入了,我們可以把梳理的領(lǐng)域模型都放到一個單體系統(tǒng)來實(shí)現(xiàn),每個限界上下文是一個package,這個是最簡單的,如果實(shí)在要做微服務(wù)拆分,限界上下文這個業(yè)務(wù)邊界也是優(yōu)先考慮的,除此以外還要綜合考慮彈性邊界,組織架構(gòu)等問題了,這個屬于微服務(wù)拆分的話題了。
總結(jié)
業(yè)務(wù)流程和領(lǐng)域模型構(gòu)成業(yè)務(wù)系統(tǒng)的核心要素,業(yè)務(wù)流程升級到業(yè)務(wù)價(jià)值流,領(lǐng)域模型升級到企業(yè)級業(yè)務(wù)對象,這就變成了企業(yè)架構(gòu)的方法(價(jià)值流+業(yè)務(wù)能力+業(yè)務(wù)對象),所以DDD和企業(yè)架構(gòu)方法是相通的,一個是微觀,一個是宏觀,兩者結(jié)合可以更好的認(rèn)識數(shù)字化建設(shè)。最后預(yù)告下篇內(nèi)容,上代碼模型。
審核編輯:劉清
-
UML
+關(guān)注
關(guān)注
0文章
122瀏覽量
31056 -
數(shù)字化
+關(guān)注
關(guān)注
8文章
9118瀏覽量
62841
原文標(biāo)題:小團(tuán)隊(duì)也能做DDD
文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
大模型領(lǐng)域常用名詞解釋(近100個)

評論