理解業務的思惟框架：數據模型+規則+語義

規則是流動的。 互聯網的美妙，在於能夠重構規則，從而革新現有的一切。

概述

中大型業務系統中，每每多種業務相互交叉，錯綜複雜，使得系統變得難以理解。通常的方法是，經過閱讀工程代碼來理解系統。但這種方法是有侷限性的。由於工程代碼，每每是系統設計實現與業務的混合體，並不徹底一致地表達着業務自己：

• 因爲當時的技術和系統架構的限制，每每實現的並非最優的業務視角，而是折衷過的；
• 部分代碼寫得比較蹩腳，表達不許確，甚至有 BUG ，反而妨礙真正理解業務自己。

要真正理解業務，須要從業務自己上去理解，嚴格區分出「業務規則」與「系統設計與實現」這兩個不一樣的層面。工程代碼，能夠做爲重要的參考。

三要素

數據模型

數據模型指的是，須要哪些數據項，數據項之間的關聯，如何有序地組織這些數據項。數據模型是軟件總體設計的導航圖。肯定良好的數據模型，設計就成功了一大半。

好比交易的基本數據模型以下。經過這個模型，能夠全局式地概覽交易所涉及到的各類基本數據、各個基礎模塊，有一個總體而基本的把握。

針對具體業務，則可更容易地理解和分析。具體業務的數據模型，一般是基礎數據模型再加上一些擴展性的數據集。

如何提煉數據模型呢 ？

能夠從工程代碼裏的各類 DO，DTO ，服務接口返回的數據對象入手。推敲每一個字段的含義，將其進行歸類。這時候，採用的是有選擇性地閱讀，閱讀代碼呈現的關鍵對象，而不是在荊棘叢生的代碼中穿梭，弄的遍體鱗傷。

規則

規則指的是，數據項及流程要知足什麼約束 ？爲了什麼目標而服務 ？

好比，爲了構建線上交易，須要一個交易下單流程。定義交易下單流程：參數校驗 -> 補全信息 -> 價格計算 -> 落庫 -> 發送建立訂單成功的消息。一個流程就是一條規則。

下單流程還能夠擴展得更完整一些：進入店鋪 -> 點擊商詳頁 -> 跳轉訂單確認頁 -> 提交訂單 -> 支付 -> 跳轉訂單支付結果頁。這個流程涉及更多的基礎服務，好比店鋪、商品、支付、優惠、物流、會員等。

還能夠定義更完整的基本線上交易流程。下單 -> 支付 -> 待發貨 -> 已發貨 -> 已簽收 -> 交易完成； 或者 下單 -> 支付 -> 待發貨 -> 退款 -> 交易關閉。

除了流程，規則也指數據項之間的約束。 好比 價格、優惠之間的計算公式，退款校驗，不支持的場景等。

關於規則最重要的一個觀點是：規則是流動的。 不要拘泥於現有的規則。徹底能夠建立新的規則。 好比線上交易是一套規則，線下交易又是一套規則，基於社交的交易又是一套規則，未來 AI 普及以後，交易或許產生全新的規則。

如何提取規則呢？ 也須要從代碼中提取。

• 流程。首先，析取最通用的流程做爲基礎；接着，再看有多出來的或剪裁的或者定製的。好比拼團訂單，從已支付到待發貨就多出來 待成團 到 已成團 的額外狀態流轉；好比虛擬商品，支付成功以後就當即變成已發貨，不通過待發貨。

• 判斷。從代碼中的各類 if-else-throw 能夠提取出來。

提取規則以後，要仔細思考，爲何要定義這樣的規則，其背後的意圖和目標是什麼？

語義

構建了數據模型和規則以後，爲了更好地擴展和發展系統的能力，須要對數據項及規則進行清晰無歧義的語義定義。有三類數據的語義要更加仔細：

• 狀態類語義。好比訂單狀態，一般涉及到業務的流轉過程，須要考慮可擴展性；當新增新的業務狀態時，可以容易地支持。
• 金額類語義。好比應付金額和實付金額。若是缺少清晰的語義，在多種業務交叉的狀況下，金額類字段就可能有多種理解和取值，很容易致使資金的故障。而資金的故障一般是最嚴重的故障類別之一。
• 標識類語義。標識類字段用於惟一標識一個實體。
  
  

經過「數據模型+規則+語義」，能夠勾勒出一個業務系統裏的基本業務圖景。

項目實戰

不下廚，永遠學不會作菜。

經過「數據模型+規則+語義」，能夠得到對業務的基本理解。不過這種理解每每是模糊不清晰的。經過項目實戰，推敲具體的業務實現細節，更深刻地理解和擴展示有數據模型、規則、語義的含義及原因。

對於具體業務，也能夠採用這種思惟框架來分析。只不過，這些都是基於通用部分而擴展出來的「數據模型+規則+語義」。

小結

本文提出了理解業務的一種有效的思惟框架：數據模型+規則+語義。經過「數據模型+規則+語義」，能夠勾勒出一個業務系統裏的基本業務圖景。不侷限於工程代碼的實現，而是致力於從業務自己的數據、規則和語義去理解，更容易貼近業務真實的意圖和目標。