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

阿里妹導讀

本文希望能夠通過總結過去自己對領域建模的一點粗淺經驗給需要的同學能有些許啟發，少走彎路。

(相關資料圖)

背景

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

總體思想

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

需求模型：通過和產品及業務同學的溝通，結合行業經驗和知識，明確用戶的真實需求； 領域模型：基于需求模型，提煉出領域相關的概念，為后面的面向對象設計打下基礎； 代碼模型：以領域模型為基礎，綜合面向對象的各種設計技巧，完成類的設計； 數據模型：以代碼模型類及類之間的關系，用ER圖刻畫數據的底層存儲關系；

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

需求建模

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

業務活動 用戶旅程 商業畫布

領域建模

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

四步建模

在我們日常工作的項目中，大多數場景都可以通過在需求用例中通過找名稱的方式來最終刻畫出領域模型，當然找到的名詞后并不是所有的都符合要求，這時可以通過一條原則"一個名詞或實體必有其屬性和行為，一屬性或行為也必歸屬于一個實體"來進行提煉，不符合這條原則的名詞就是需求剔除的。總體來說建模一共分為四步

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

需求用例

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

建模步驟 ?

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

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

所以最終提取的領域實體是：用戶、商品、用戶檔案、子訂單、訂單、商家 ?

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

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

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

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

第四步： 連關系 。關系主要表達模型和模型之間怎樣協作 ?

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

歸類分組

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

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

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

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

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

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

生活服務類商品場景

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

歸類分組建模過程：

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

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

第四步；產出領域模型

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

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

事件風暴

為什么引入事件風暴。 事件風暴之一的作用就是拉通業務方、產品、研發、測試對業務知識的統一理解，避免各方理解誤差。但在實際操作中受限于各方時間協調的難度及領域專家的角色的缺失，事件風暴往往作為理解業務，領域建模及領域劃分的利器去使用。

什么是事件風暴。 事件風暴是一種以工作坊的方式對復雜業務領域進行探索的高效協作方法，事件風暴強調以事件驅動團隊探索分析業務領域。

一種捕獲行為需求的方法 強調以先發散后收斂的方式開展 相關干系人協作的方式進行 注重對領域事件的識別

事件風暴相關元素

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

? 事件風暴操作流程

識別重要事件 識別命令 識別執行者和讀模型 識別領域對象 產出領域模型

產品截圖

識別重要事件? 識別命令? 識別執行者和讀模型 識別領域對象

這里說的領域對象，是從命令、領域事件、執行者、查詢數據里找到的名詞性概念。例如，對于簽訂合同這個命令而言，受到影響的名詞性概念是“合同”；類似地，對于合同已簽訂這個領域事件，是由于“合同”這個名詞性概念的狀態變化所導致的。

產出領域模型

? ?

四色建模

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

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

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

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

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

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

產品截圖

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

通過對業務的梳理可以產出了四色原型圖的關鍵業務時刻，如下面表格

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

通過上面的表格大概知道用戶在IM應用中的關鍵業務時刻和對象 ?

尋找關鍵業務時刻對象周圍的人、事、物對象 ?

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

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

產出領域模型

限界筆紙法

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

建模步驟

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

分析模式

學會了上面的建模方法就有能力應對開發中等難度的系統了。不過，如果遇到更復雜的業務領域，還需要更深入的建模技能。《分析模式》是 Martin Fowler 寫的一本領域建模的專著。講述各種分析模式和輔助模式，專注于面向對象分析與設計的結果——模型本身，給出了來自金融貿易、測量、財務以及組織關系等多個領域內的一系列模式。書中每個模式都包含了設計背后的原理、使用的規則以及實現的技巧，給出的例子包含了有用模型的細節，并介紹了用于提高分析、建模和實現的重用技巧。研究不深感興趣的可以看下。

代碼建模

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

第一步：完成領域類到代碼類的映射 類：領域模型中的類直接映射成代碼里的類 屬性：領域模型類的屬性直接映射成代碼類里的屬性 動作：領域模型類的動作直接映射成代碼類里的方法 狀態機：領域模型里的狀態映射為類的狀態機 協作關系：用UML的類關系圖重新刻畫協作關系

以上面的一個領域模型為例

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

數據建模

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

怎么判斷模型好不好

領域模型是生活中模型的映射。 在幾十年前，我們沒有計算機，但是我們仍然可以通過白紙黑字的方式完成我們的業務。換句話說，我們的業務系統只是把一個紙質的單據變成了電腦里存在數據庫里的東西。也就是說，我們的模型，一定是在生活中有實際的對應的單據，而且名字也應該是一致的。千萬不要臆造概念。 領域模型不是DB模型。 領域模型不是DB模型，一個領域對象可以有多種方式映射到數據庫，但是我們聊領域模型的時候，一定不是聊DB模型，重要的一定是描述清楚業務概念。在做ORM的時候，如果有繼承關系需要的實現的時候，我們再考慮是單表繼承（Single Table Inheritance）還是實體表（Concrete Table Inheritance）等模式。 領域模型的關系一定是穩定的。 當接到一個新的需求時，如果發現模型的關系不匹配了，那說明之前的模型設計的肯定存在問題，好的模型實體和實體之間的關系一定是穩定的，只會新增不會對原有關系進行改變。

領域模型為什么要一直持續迭代

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

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

背后需要修煉的思維

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

阿里云開發者社區，千萬開發者的選擇

阿里云開發者社區，百萬精品技術內容、千節免費系統課程、豐富的體驗場景、活躍的社群活動、行業專家分享交流，歡迎點擊【閱讀原文】加入我們。

關鍵詞：