本文通過實際業務需求場景建模案例，為讀者提供一種業務模型向數據模型設計的方法論，用於指導實際開發中如何進行業務模型向數據模型轉化抽象，並對設計的數據模型可用性、擴展性提供了建議性思考。通過文章，讀者可以收穫到業務模型向數據模型抽象可參考的一種方法論，並針對後期業務需求變化，儘可能降低模型調整或者模型推a倒重建的風險。本文可以重點關註建模實施流程，針對自己實際業務場景，不斷抽象優化自己的數據模型。

一、背景

從研發人員的角度出發，技術更多的是為業務賦能，同時研發人員也可以通過業務模型設計來提升自己的技術，他們更多的是技術控，追求擁有更多的技術棧。不過今天不討論具體的技術，準備換一種思維模式來分享下自己在業務開發中的一些經驗，並結合實際案例來闡述針對業務場景進行數據建模的方法論。

開發人員在日常工作中，參與PRD評審、聽產品經理講述用戶故事、提出各種需求。評審結束，一般會一股腦投入到設計開發，而資料庫表設計就是其中不可或缺的一個過程。對於熟悉的業務模塊，通過對需求分析，可以輕而易舉的完成數據表設計，但對於非熟悉業務領域，可能會經過多輪PRD分析，整理一套數據表結構基礎，然後對其追加欄位，就完成了基礎的數據模型設計。而在這個過程中，往往會感覺沒有可以參考的理論，有時候甚至對設計的資料庫表產生懷疑，不斷考慮此設計是否符合業務、表結構設計後期是否具有通用性、表之間關係是否恰當可擴展等等。今天來談些在實際業務開發中，針對數據建模的一些思考。

一個好的方法論一定是告訴你當你面對一個全新的業務場景或未知領域的時候，如何去獨立分析和解決問題。

二、名詞

領域：可以理解為傳統軟體需求分析中的業務場景對應的業務域，比如常見的電商、物流、運輸等領域。

子域：領域的部分業務域，比如電商的部分訂單、支付、庫存等子域。

建模：業務域的映射和抽象。

三、思考

面向對象分析的設計思維模式：

圖1. 用戶角度到開發角度思考

四、方法論

4.1  實施步驟

1. 識別對象；
2. 組織對象；
3. 定義對象模型間關係；
4. 完善模型細節（屬性、狀態）；
5. 領域模型到數據模型映射；

4.2 CASE實踐（社區團購--預排線調度建模案例）

(1)PRD需求描述

預排線系統從OFC系統獲取團單數據：截單之前每天下午OFC推送一份當天需要預排線的數據出來，這些數據包括每個已經成團的團單（生產單）和截止到當前時間團單的商品數據，這裡麵包含當天已經取消的團單（即所有的商品數量都是0）。同時在截單之後，OFC會把截單後的團單數據再推送一次，裡面包含當天已經取消的團單（所有的商品數量都是0）；

團單數據創建、更新、刪除：如果下發的生產單號在預排線系統不存在，則創建團單信息；如果下發的生產單號在預排線系統存在，則更新下麵單商品的數量、團單的收件地址、經緯度、團長ID、姓名、電話等信息；如果有新增的商品則添加團單下的商品數據；如果更新的團單數量，其下麵所有商品的個數都為0，代表這個團單已經被取消，則邏輯刪除這個團單，同時取消這個團單和對應線路的綁定關係；更新的商品數量都是更新的商品的當前數量，不會更新調度時的數量和實際的數量。

(2)識別對象

Note：

1. 復用或者修改已有模型（比如：運輸需求、計劃、詢價單、對賬單、財務賬單等）；
2. 行業、公司內概念列表（比如：社區團購、分揀、調度、詢價、計費等）；
3. 名詞。

識別出的對象：

OFC 團單 單 預排線數據 生產單 商品 商品數量 預排線系統 團單收件地址 經緯度 團長ID 姓名 電話 線路 商品當前數量 調度時的數量 實際數量

(3)組織對象

Note：

1. 一詞多用、重覆、歧義：歸結為一個對象模型；
2. 複數：students --> student 歸結為一個對象模型；
3. 屬性：可以歸結為對象模型的特征，不單獨升級為一個對象，但特殊場景下，比如文章的分類可以為文章的一個屬性，但是當分類又有子屬性時，比如有子屬性標簽，這時可以把分類單獨升級為對象模型。類似設計資料庫表，是設計為欄位還是新設計一張表一樣。

分析對象：

1. OFC ：系統
2. 團單：生產單 單 團單收件地址 經緯度 團長ID 姓名 電話
3. 預排線：預排線系統，預排線模型 線路
4. 商品：商品 商品數量 商品當前數量 調度時的數量 實際數量

(4)定義對象模型關係

Note：

1. 外鍵
2. 關係：一對一、一對多、多對多，關係傳遞

分析關係：

1. "同時取消這個團單和對應線路的綁定關係" -----> 預排線包括多個團單，預排線 VS 團單= one vs many
2. "如果有新增的商品則添加團單下的商品數據" -----> 團單下有多個商品，團單 VS 商品 = one vs many

圖2. 模型間關係

(5)完善模型信息（屬性狀態）

Note：

1. 子域：模型對象的子對象信息，比如：店鋪模型下的員工模型、地址庫模型、員工薪資模型等。
2. 屬性：模型對象的特征表現
3. 狀態：狀態機
4. 邊界：對象模型間交互部分，分清楚哪些屬於A對象哪些是B對象

完善對象模型：

圖3.對象模型(模擬欄位信息)

（6）領域對象到數據模型

Note：

1. 派生：數據模型之間的一種關聯、繼承、映射出的一種關係。比如“預排線模型”中“運輸任務編碼”屬性，屬於調度域的模型屬性，後期會與調度域系統產生關聯關係，所以把運輸任務編碼作為“預排線模型”的一個派生屬性。
2. 冗餘：①低級冗餘（顯示）--模型依賴外部模型屬性欄位顯示使用，這時不用再關聯查詢或者通過IO獲取；②高級冗餘（計算）--比如外部模型有單價、數量屬性且穩定不變，則模型可以依賴其計算結果，省去二次計算邏輯；
3. 擴展表：①數據模型的垂直拆分，減少大對象；②變更不是很頻繁的欄位可以放到擴展模型；

社區團購排線部分模型設計圖：

圖4 終版數據模型圖

五、擴展

5.1 領域模型設計階段思考

對象：領域模型對象，上述案例分析到的對象模型；

功能：哪些業務功能劃分到領域（微服務）或者子域（模塊）裡面

介面：服務應該暴露的介面能力；

5.2  方法論

動詞+賓語 <----> 方法介面+對象

• 業務功能操作和實體對象分離，更容易進行微服務劃分；
• 某個微服務應該暴露哪些介面；
• 領域上下文邊界，介面應屬於哪個領域提供。

圖5 領域模型調用關係圖

五、結語

一個好的方法論一定是告訴你當你面對一個全新的業務場景或未知領域的時候，如何去獨立分析和解決問題。

作者：京東物流 鄭朋輝

來源：京東雲開發者社區