修冶 阿里云開發(fā)者 2023-08-24 08:31 發(fā)表于浙江

阿里妹導讀

本文希望能夠通過總結(jié)過去自己對領(lǐng)域建模的一點粗淺經(jīng)驗給需要的同學能有些許啟發(fā)，少走彎路。

(相關(guān)資料圖)

背景

軟件工程師做的核心事情就是對現(xiàn)實世界的問題進行抽象然后用計算機的語言對其進行重新刻畫，在通過信息化來提高生產(chǎn)力。而這其中一個關(guān)鍵環(huán)節(jié)就是如何對問題域進行建模，在過去的工作中經(jīng)常遇到一個問題是前期因為業(yè)務比較簡單所以設計的模型在支撐時沒有發(fā)現(xiàn)什么問題而隨著業(yè)務復雜度的增加就會發(fā)現(xiàn)需要對模型進行升級，如果是對模型關(guān)系維度的新增那還好，而如果是對原有模型關(guān)系的重構(gòu)，那將會變的非常困難。本文希望能夠通過總結(jié)過去自己對領(lǐng)域建模的一點粗淺經(jīng)驗給需要的同學能有些許啟發(fā)，少走彎路。

總體思想

關(guān)于如何建模并不是一個單一維度的問題而是一個體系化的工程，我們需要對其進行拆解然后逐個攻破，如何建好模并能順利落地可以拆分為四個子問題，1）對需求進行功能建模 2）對業(yè)務進行領(lǐng)域建模 3）將領(lǐng)域模型映射到代碼模型 4）根據(jù)代碼模型落地數(shù)據(jù)模型。 ?

需求模型：通過和產(chǎn)品及業(yè)務同學的溝通，結(jié)合行業(yè)經(jīng)驗和知識，明確用戶的真實需求； 領(lǐng)域模型：基于需求模型，提煉出領(lǐng)域相關(guān)的概念，為后面的面向?qū)ο笤O計打下基礎； 代碼模型：以領(lǐng)域模型為基礎，綜合面向?qū)ο蟮母鞣N設計技巧，完成類的設計； 數(shù)據(jù)模型：以代碼模型類及類之間的關(guān)系，用ER圖刻畫數(shù)據(jù)的底層存儲關(guān)系；

還有一個重要的認知，領(lǐng)域建模并不是萬能的，比如你做的系統(tǒng)很簡單，使用數(shù)據(jù)庫的CRUD可能一個更好的方式(如上圖中的虛線箭頭)，如果做的是基礎架構(gòu)，比如開發(fā)一個RPC框架，也不需要用領(lǐng)域驅(qū)動。運用領(lǐng)域驅(qū)動的前提一定是業(yè)務足夠復雜且多變，需要系統(tǒng)靈活支持。下面這個圖供參考： ?

需求建模

萬事開頭難，需求是項目最開始的輸入，肯定是非常重要的，但現(xiàn)實情況往往是當我們接到需求后第一個想到的問題確是我該如何實現(xiàn)，而沒有在業(yè)務思考這一塊過多的停留。如果最開始理解的輸入是錯誤的，后面的過程再優(yōu)秀可想而知也只能是垃圾。為了解決這一問題，很多優(yōu)秀的大佬發(fā)明了很多對需求進行功能建模的工具，主要目的就是讓我們更好的理解需求并認識其背后的本質(zhì)。如常用的工具有5w2h、業(yè)務活動、用戶旅程、商業(yè)畫布等。這些在網(wǎng)上都有很多的資料，只舉幾個例子，不做重點介紹。

業(yè)務活動 用戶旅程 商業(yè)畫布

領(lǐng)域建模

下面的每一種方法都是從某一個角度幫助我們更好理解客觀事物，所以沒有哪一種方法是萬能的，在實際項目中常常要多種方法共用，才可能認清事情的全貌。

四步建模

在我們?nèi)粘９ぷ鞯捻椖恐?，大多?shù)場景都可以通過在需求用例中通過找名稱的方式來最終刻畫出領(lǐng)域模型，當然找到的名詞后并不是所有的都符合要求，這時可以通過一條原則"一個名詞或?qū)嶓w必有其屬性和行為，一屬性或行為也必歸屬于一個實體"來進行提煉，不符合這條原則的名詞就是需求剔除的?？傮w來說建模一共分為四步

選名詞：從用例中選出所有名詞，在去偽存真選出符合要求的； 找動詞：找出所有動詞，在判斷這些動詞屬不屬于上一步選出的名詞所具有的行為； 加屬性：找出所有屬性，在判斷這些屬性屬不屬于上一步選出的名詞所具有的特征； 連關(guān)系：確定實體和實體之間的協(xié)作關(guān)系；?

需求用例

用例名稱	用戶購買商品
用例描述	1、用戶在購物app上選取多款商品進行下單 2、通過用戶檔案獲取用戶名稱、地址等信息 3、從不同商家購買的商品生成不同的子訂單；記錄商品及其數(shù)量，并匯總付款金額 4、保存訂單 5、選擇一種支付方式(包括銀行卡、支付寶、微信)并進行支付；超過30分鐘未支付自動取消訂單
約束和限制	1、一個商品單次購買不能超過30單 2、單次支付金額最大不能超過99999RMB

建模步驟 ?

第一步： 選名詞 。從用例上選的名詞如下：用戶、購物app、商品、用戶檔案、用戶名稱、地址、商家、訂單、子訂單、支付方式、銀行卡、支付寶、微信。通過這種方式可以很輕松的識別領(lǐng)域中的相關(guān)概念，但選取的名詞并不一定都是領(lǐng)域相關(guān)的，所以接下來還需要進一步的提煉。提煉過程

刪除"購物app"：購物app只是一個功能的載體，并不屬于購買商品流量里的一個領(lǐng)域概念，所以刪掉 刪除"用戶名稱" ：用戶名稱只是用戶的一個屬性，并不是領(lǐng)域概念 刪除"地址" ：地址只是用戶檔案的一個屬性，并不是領(lǐng)域概念 刪除"銀行卡、支付寶、微信、支付方式"：銀行卡、支付寶、微信屬于支付方式的一種具體形式，而支付方式可以歸屬為訂單的一個屬性，并不是獨立的領(lǐng)域概念

所以最終提取的領(lǐng)域?qū)嶓w是：用戶、商品、用戶檔案、子訂單、訂單、商家 ?

第二步： 找動詞 。從用例上選的動詞如下：選取、匯總、下單、保存、支付、取消

找動詞的目的是反向檢查是否有遺漏的實體沒有提煉出來，因為有些隱含的概念并不一定能在用例里找到，且一個動作必歸屬于一個實體。如果有發(fā)現(xiàn)動作沒有歸屬實體只有2種情況，一是這個動作不屬于這個領(lǐng)域，二是有遺漏的實體沒有提取出來。經(jīng)過分析 "選取" 是用戶主觀的一種行為，并不屬于這個領(lǐng)域所以刪掉，"下單、匯總、保存、支付、取消" 都屬于訂單的動作。 ?

第三步： 加屬性 。理論上產(chǎn)品同學要在用例上把模型的所有屬性全部列出來，但現(xiàn)實情況不一定能做到，這時除了用例還需要當面和產(chǎn)品對焦清楚各個模型的屬性。

名詞	屬性
用戶	用戶名稱、性別、證據(jù)類型、手機號
商品	商品名稱、單價、商家、商品類別、商品編碼
用戶檔案	國家、省份、地市、區(qū)縣、地址詳情、聯(lián)系電話
子訂單	商品、數(shù)量、單價、金額
訂單	用戶、地址、金額、下單時間
商家	商家名稱、經(jīng)營地址、經(jīng)營范圍、聯(lián)系人、聯(lián)系電話 ?

第四步： 連關(guān)系 。關(guān)系主要表達模型和模型之間怎樣協(xié)作 ?

補充場景：比如 "一個客戶想入駐平臺成為一個服務商"，按照上述方法提煉出動詞"入駐"，但會發(fā)現(xiàn)其并不適合成為"客戶"、"平臺"、"服務商"實體的行為，因此可以反向推出還應存在另外一個實體"入駐申請單"的概念，"入駐" 這個動詞更準確的叫法是"申請入駐"。

歸類分組

歸類分組，就是把具有相似性或相關(guān)聯(lián)的信息，按照一定的標準進行分類，歸為同一個邏輯范疇。“類”是一個極其重要的概念，可以看作本質(zhì)相同或相似的事物的集合。分類就是按照一定的標準，根據(jù)對象屬性、特征的共同點和不同點，將對象劃分為不同的種類。分類時，需要對這些類別進行鑒定、描述和命名。

分類在生活中無處不在。通過分類，一方面可以把雜亂無序的事物區(qū)分開來；另一方面還要賦予不同類別以穩(wěn)定的、概念化的名稱。一個好的命名，能夠簡潔有力地表述事物的本質(zhì)。分類的過程，就是探尋事物和問題本質(zhì)的過程。

如何用歸類分組進行領(lǐng)域建模可以分為3個步驟

第一步：定義要建模的領(lǐng)域問題：也就是要清楚我們要解決的問題是什么？

第二步：對領(lǐng)域問題進行拆解：對問題進行分析拆解，形成平鋪的多個子問題，此步驟可以盡量發(fā)散

第三步：歸類分組：對子問題進行歸類，剪枝，將趨同的子問題，合并成一類（可以理解問產(chǎn)出實體）

生活服務類商品場景

預定類商品（KTV預定、休娛預定、麗人預定等）： 可以按照周期設置每周的價格；支持設定節(jié)假日的價格； 業(yè)務特點：商品價格同樣呈周期性變化，有特殊日期以及不可用日期；計價方式包括按人、按間 場館預定類

歸類分組建模過程：

第一步：定義要建模的領(lǐng)域問題：從上面的售賣商品場景可以看出一個商品有多個價格；而決定這個價格的是由一系列的因子決定的，有可能是0個也可能是多個；如何用一套完備的價格模型來支持這些場景是需要解決的問題； 第二步：對領(lǐng)域問題進行拆解：羅列出所有商品價格的場景； 第三步：歸類分組： 按人群、日期、階梯、座位等類型，可以統(tǒng)一抽象為價格的不同"維度" 原價、起拍價、保證金、評估價等可以看做室價格的不同類型

所以一個價格由什么決定：sku的價格 = 價格類型 + 價格維度 + 具體價格，具體抽象過程如下：

第四步；產(chǎn)出領(lǐng)域模型

商家成長：為不同層級的商家門店下發(fā)不同類型的任務，完成對應的任務，商家會獲取到對應的權(quán)益，進而幫助商家在平臺的不同階段能夠更好的成長。

第一步：定義要建模的領(lǐng)域問題，針對門店維度為商家建立一套任務體系，不同的門店可以下發(fā)不同的系列任務 第二步：略 第三步： 基礎裝修、商品優(yōu)化、服務評價等屬于一個維度，可以抽象為"任務流" 門店圖、手藝人、是否有品牌故事等屬于一個維度，可以抽象為"任務" 而由"門店圖、手藝人"等任務組成的基礎裝修，可以抽象為"任務組" 門店圖片里又包含指標和完成的跳轉(zhuǎn)動作，可以分別抽象為"任務指標","任務動作" 第四步；產(chǎn)出領(lǐng)域模型

事件風暴

為什么引入事件風暴。 事件風暴之一的作用就是拉通業(yè)務方、產(chǎn)品、研發(fā)、測試對業(yè)務知識的統(tǒng)一理解，避免各方理解誤差。但在實際操作中受限于各方時間協(xié)調(diào)的難度及領(lǐng)域?qū)＜业慕巧娜笔?，事件風暴往往作為理解業(yè)務，領(lǐng)域建模及領(lǐng)域劃分的利器去使用。

什么是事件風暴。 事件風暴是一種以工作坊的方式對復雜業(yè)務領(lǐng)域進行探索的高效協(xié)作方法，事件風暴強調(diào)以事件驅(qū)動團隊探索分析業(yè)務領(lǐng)域。

一種捕獲行為需求的方法 強調(diào)以先發(fā)散后收斂的方式開展 相關(guān)干系人協(xié)作的方式進行 注重對領(lǐng)域事件的識別

事件風暴相關(guān)元素

事件：重要且已發(fā)生的事情。命名方式：完成時+被動語態(tài)=賓語+動詞過去式 命令：產(chǎn)生事件觸發(fā)的動作 角色/執(zhí)行者：觸發(fā)命令的主體，包括：人員、系統(tǒng)、定時任務 讀模型：執(zhí)行者決策執(zhí)行命令時參考的視圖元素

? 事件風暴操作流程

識別重要事件 識別命令 識別執(zhí)行者和讀模型 識別領(lǐng)域?qū)ο? 產(chǎn)出領(lǐng)域模型

產(chǎn)品截圖

識別重要事件? 識別命令? 識別執(zhí)行者和讀模型 識別領(lǐng)域?qū)ο?

這里說的領(lǐng)域?qū)ο?，是從命令、領(lǐng)域事件、執(zhí)行者、查詢數(shù)據(jù)里找到的名詞性概念。例如，對于簽訂合同這個命令而言，受到影響的名詞性概念是“合同”；類似地，對于合同已簽訂這個領(lǐng)域事件，是由于“合同”這個名詞性概念的狀態(tài)變化所導致的。

產(chǎn)出領(lǐng)域模型

? ?

四色建模

關(guān)于四色建模的概念我們可與追溯到90年代，是被廣泛使用的一種系統(tǒng)分析方法。四色建模的目的是要對目標業(yè)務系統(tǒng)進行分析并通過不同的顏色標示出人，事，物，角色，通過四色建模得到四色原型圖，每個原型圖有屬性和連接（關(guān)聯(lián)與依賴等關(guān)系）兩個部分組成。

那四色原型具體是哪四色呢？一起來看看

時標原型（Moment-Interval Archetype，簡稱MI） 表示事物在某個時刻或某一段時間內(nèi)發(fā)生的，如銷售訂單、收款記錄等，使用淺紅色表示。 PPT原型（Part-Place-Thing Archetype，人/事/物原型，簡稱PPT） 表示參與扮演不同角色的人或事物，如商品、賬戶、店鋪等，使用淺綠色表示。 角色原型（Role Archetype，簡稱ROLE） 抽象了一種參與方式，由人或組織機構(gòu)、地點或物品來承擔，如客戶、商家、財務組織等，使用淺黃色表示。 描述原型（Description Archetype，簡稱DESC） 對上述顏色表示的內(nèi)容進行解釋，用于分類或者描述建模過程中產(chǎn)生的數(shù)據(jù)，事件，或者活動，使用淺藍色表示。

用一句話來概括四色原型就是： 一個什么樣的人或物品以某種角色在某個時刻或某段時間內(nèi)參與某個活動。其中“什么樣的”就是DESC，“人或物品”就是PPT,”角色”就是ROLE,而“某個時刻或某個時間段內(nèi)的某個活動”就是MI。

接下來使用四色建模法來分析領(lǐng)域模型，總共分為四大步：

建立時標原型： 尋找需要追溯的事件，根據(jù)追溯事件尋找足跡 建立PPT原型： 豐富模型，尋找時標原型周圍的人/事/物，使它可以更好地描述業(yè)務概念 建立角色原型： 進一步從中抽象出可以參與到不同流程中去的角色 建立描述原型： 把一些信息用描述對象補足

產(chǎn)品截圖

梳理咨詢業(yè)務時序 ，任何的業(yè)務事件都會以某種數(shù)據(jù)的形式留下足跡。我們對于事件的追溯可以通過對數(shù)據(jù)的追溯來完成，當我們把這些數(shù)據(jù)的足跡按照時間順序排列起來，就可以清晰的推測出過往的一段時間內(nèi)發(fā)生的事情。 ?

通過對業(yè)務的梳理可以產(chǎn)出了四色原型圖的關(guān)鍵業(yè)務時刻，如下面表格

關(guān)鍵業(yè)務活動	關(guān)鍵業(yè)務時刻對象	備注
注冊到店app賬號	用戶賬號信息
建群	群關(guān)系記錄	用戶點擊咨詢會自動創(chuàng)建群
聊天	群消息	通過群聊實現(xiàn)不同客服的接待
打電話	電話記錄	用戶也可以通過打電話直接咨詢商家
留資	客資信息
視頻面診	面診記錄

通過上面的表格大概知道用戶在IM應用中的關(guān)鍵業(yè)務時刻和對象 ?

尋找關(guān)鍵業(yè)務時刻對象周圍的人、事、物對象 ?

從人,事,物中抽象出角色

把一些描述信息用對象補足 ?

產(chǎn)出領(lǐng)域模型

限界筆紙法

限界筆紙法起源于thoughtworks，由thoughtworks大佬提出的基于四色建模的改進方法。在“四色建模法”的“時標對象”的基礎上確定"限界上下文”與“聚集”的概念，再使用“紙和筆來管理”的方法，力圖在建模過程中實現(xiàn)“分而治之”，增強數(shù)據(jù)的完整性，并避免過度設計。

建模步驟

根據(jù)“業(yè)務發(fā)生時刻”的價值識別核心領(lǐng)域(core domain) 確定核心領(lǐng)域之間的依賴關(guān)系 用紙和筆畫表格并寫實例（這里的實例可以是業(yè)務用例，用戶故事，或者業(yè)務發(fā)生時刻） 確定“聚合根 （AGGREGATE ROOT）” 以“人以群分”的原則抽取新的“聚合”

分析模式

學會了上面的建模方法就有能力應對開發(fā)中等難度的系統(tǒng)了。不過，如果遇到更復雜的業(yè)務領(lǐng)域，還需要更深入的建模技能?！斗治瞿Ｊ健肥?Martin Fowler 寫的一本領(lǐng)域建模的專著。講述各種分析模式和輔助模式，專注于面向?qū)ο蠓治雠c設計的結(jié)果——模型本身，給出了來自金融貿(mào)易、測量、財務以及組織關(guān)系等多個領(lǐng)域內(nèi)的一系列模式。書中每個模式都包含了設計背后的原理、使用的規(guī)則以及實現(xiàn)的技巧，給出的例子包含了有用模型的細節(jié)，并介紹了用于提高分析、建模和實現(xiàn)的重用技巧。研究不深感興趣的可以看下。

代碼建模

經(jīng)過領(lǐng)域模型的分析后，面向?qū)ο笠呀?jīng)初具雛形，但領(lǐng)域類并不能指導我們進行編碼工作，因為領(lǐng)域類只是從用例模型中提煉出來的反映業(yè)務領(lǐng)域的概念，并不是真正意義上的軟件類，我們要需要在進一步，完成領(lǐng)域類到軟件類的轉(zhuǎn)換，這就是代碼建模階段的主要任務。那么具體如何做的 ?

第一步：完成領(lǐng)域類到代碼類的映射 類：領(lǐng)域模型中的類直接映射成代碼里的類 屬性：領(lǐng)域模型類的屬性直接映射成代碼類里的屬性 動作：領(lǐng)域模型類的動作直接映射成代碼類里的方法 狀態(tài)機：領(lǐng)域模型里的狀態(tài)映射為類的狀態(tài)機 協(xié)作關(guān)系：用UML的類關(guān)系圖重新刻畫協(xié)作關(guān)系

以上面的一個領(lǐng)域模型為例

第二步：應用設計原則和設計模式。 完成了第一步，類就出來了，屬性和方法也有了，是不是就結(jié)束了呢，如果按照設計原則的衡量標準，會發(fā)現(xiàn)第一步只是最基本的要求，而不是一個好的設計。還以"用戶購買商品"案例為例，支付的方式分為支付寶、微信、銀行卡，運用設計模式后，代碼模型變成如下：

數(shù)據(jù)建模

數(shù)據(jù)模型推導的來源是領(lǐng)域模型。一般原則，領(lǐng)域模型中的實體映射為數(shù)據(jù)庫中的表；領(lǐng)域模型中的屬性，映射成表中的字段，同時還要根據(jù)需求補充更多的字段。模型中的一個一對多關(guān)聯(lián)，可以映射成一個外鍵字段，以及一個外鍵約束。但一般不會真的建立外鍵約束，而外鍵的邏輯關(guān)系還是存在的?？梢杂锰摼€箭頭表示這種邏輯上的外鍵關(guān)系，稱為虛擬外鍵。對于多對多關(guān)聯(lián)，必須增加一個關(guān)聯(lián)表，其中包括了兩個實體表各自的主鍵。另外，關(guān)聯(lián)上的多重性決定了外鍵字段的非空約束。 ?

怎么判斷模型好不好

領(lǐng)域模型是生活中模型的映射。 在幾十年前，我們沒有計算機，但是我們?nèi)匀豢梢酝ㄟ^白紙黑字的方式完成我們的業(yè)務。換句話說，我們的業(yè)務系統(tǒng)只是把一個紙質(zhì)的單據(jù)變成了電腦里存在數(shù)據(jù)庫里的東西。也就是說，我們的模型，一定是在生活中有實際的對應的單據(jù)，而且名字也應該是一致的。千萬不要臆造概念。 領(lǐng)域模型不是DB模型。 領(lǐng)域模型不是DB模型，一個領(lǐng)域?qū)ο罂梢杂卸喾N方式映射到數(shù)據(jù)庫，但是我們聊領(lǐng)域模型的時候，一定不是聊DB模型，重要的一定是描述清楚業(yè)務概念。在做ORM的時候，如果有繼承關(guān)系需要的實現(xiàn)的時候，我們再考慮是單表繼承（Single Table Inheritance）還是實體表（Concrete Table Inheritance）等模式。 領(lǐng)域模型的關(guān)系一定是穩(wěn)定的。 當接到一個新的需求時，如果發(fā)現(xiàn)模型的關(guān)系不匹配了，那說明之前的模型設計的肯定存在問題，好的模型實體和實體之間的關(guān)系一定是穩(wěn)定的，只會新增不會對原有關(guān)系進行改變。

領(lǐng)域模型為什么要一直持續(xù)迭代

要在"變化的現(xiàn)實世界中尋找不變性"，希望尋找到一個穩(wěn)定的領(lǐng)域模型，讓系統(tǒng)流程可以靈活改變，模型不怎么變，但在實際中卻很難完美的做到，這是為什么呢？（備注：這里的迭代不是指對原有模型關(guān)系的重構(gòu)，而是對模型新關(guān)系的升級）

意識問題。在用戶、產(chǎn)品人員、運營人員眼中，溝通的語音是"流程"而不是"模型"。開發(fā)人員在與他們的溝通過程中，慢慢就形成了以"流程"為主導，而不是以"模型"為主導的思維方式。這使得整個開發(fā)過程是"流程驅(qū)動"，而不是"領(lǐng)域驅(qū)動"。大家在討論業(yè)務與系統(tǒng)解決方案的時候，大部分時間都花在了業(yè)務流程、業(yè)務規(guī)則上，而不是深刻挖掘流程背后的不變因素。 現(xiàn)實世界的復雜性。業(yè)務也就是我們的現(xiàn)實世界，灰度的、模棱兩可的東西，比計算機的世界多得多，變化也多得多。很難確定有哪些東西是不怎么變的，什么東西是容易變的，而這恰恰是做建模的前提條件。 迭代速度。在穩(wěn)固的模型，也不可能一成不變，畢竟現(xiàn)實世界一直在變。當現(xiàn)實世界變化到模型不能支撐的時候，要能馬上修改模型才行。但實際情況是，因為開發(fā)效率的原因，工期趕不上，然后就會在舊的模型上進行打補丁，補丁一個接著一個打，最后整個系統(tǒng)臃腫不堪，開發(fā)效率進一步降低，如此惡性循環(huán)。 ? 火候的掌握。領(lǐng)域模型是要對現(xiàn)實世界建模，既要去尋找不變性，又要為可能變化的地方留出擴展性。什么地方是不變的，要作為基礎；什么地方是易變的，要留出擴展性，這其中并沒有一個標準原則。另外，各家公司的業(yè)務規(guī)模、速度不一樣，團隊實施能力也不一樣。所以在實踐中，要么會"缺乏設計"，要么會"過度設計"。對火候的掌握，需要有悟性。只有反復思考，反復推翻自己之前的想法，再重建新的想法，才能在實踐中不斷找到領(lǐng)域模型、業(yè)務發(fā)展速度、技術(shù)團隊能力之間的"最佳平衡點"。

背后需要修煉的思維

上面講的這些都是術(shù)的表現(xiàn)，是借假修真，只有"真"才是我們修煉的道，也就是做事的思維，下圖列舉一些，歡迎感興趣的多交流。 ?

阿里云開發(fā)者社區(qū)，千萬開發(fā)者的選擇

阿里云開發(fā)者社區(qū)，百萬精品技術(shù)內(nèi)容、千節(jié)免費系統(tǒng)課程、豐富的體驗場景、活躍的社群活動、行業(yè)專家分享交流，歡迎點擊【閱讀原文】加入我們。

關(guān)鍵詞：