規則是流動的。 互聯網的美妙，在於可以重構規則，從而革新現有的一切。
概述###
中大型業務系統中，往往多種業務相互交叉，錯綜復雜，使得系統變得難以理解。一般的方法是，通過閱讀工程代碼來理解系統。但這種方法是有局限性的。因為工程代碼，往往是系統設計實現與業務的混合體，並不完全一致地表達着業務本身：
- 由於當時的技術和系統架構的限制，往往實現的並不是最優的業務視角，而是折衷過的；
- 部分代碼寫得比較蹩腳，表達不准確，甚至有 BUG ，反而妨礙真正理解業務本身。
要真正理解業務，需要從業務本身上去理解，嚴格區分出“業務規則”與“系統設計與實現”這兩個不同的層面。工程代碼，可以作為重要的參考。
三要素###
數據模型####
數據模型指的是，需要哪些數據項，數據項之間的關聯，如何有序地組織這些數據項。數據模型是軟件整體設計的導航圖。確定良好的數據模型，設計就成功了一大半。
比如交易的基本數據模型如下。通過這個模型，可以全局式地概覽交易所涉及到的各種基本數據、各個基礎模塊，有一個整體而基本的把握。
針對具體業務，則可更容易地理解和分析。具體業務的數據模型，通常是基礎數據模型再加上一些擴展性的數據集。
如何提煉數據模型呢 ？
可以從工程代碼里的各種 DO，DTO ，服務接口返回的數據對象入手。推敲每個字段的含義，將其進行歸類。這時候，采用的是有選擇性地閱讀，閱讀代碼呈現的關鍵對象，而不是在荊棘叢生的代碼中穿梭，弄的遍體鱗傷。
規則####
規則指的是，數據項及流程要滿足什么約束 ？為了什么目標而服務 ？
比如，為了構建線上交易，需要一個交易下單流程。定義交易下單流程：參數校驗 -> 補全信息 -> 價格計算 -> 落庫 -> 發送創建訂單成功的消息。一個流程就是一條規則。
下單流程還可以擴展得更完整一些：進入店鋪 -> 點擊商詳頁 -> 跳轉訂單確認頁 -> 提交訂單 -> 支付 -> 跳轉訂單支付結果頁。這個流程涉及更多的基礎服務，比如店鋪、商品、支付、優惠、物流、會員等。
還可以定義更完整的基本線上交易流程。下單 -> 支付 -> 待發貨 -> 已發貨 -> 已簽收 -> 交易完成； 或者 下單 -> 支付 -> 待發貨 -> 退款 -> 交易關閉。
除了流程，規則也指數據項之間的約束。 比如 價格、優惠之間的計算公式，退款校驗，不支持的場景等。
關於規則最重要的一個觀點是：規則是流動的。 不要拘泥於現有的規則。完全可以創建新的規則。 比如線上交易是一套規則，線下交易又是一套規則，基於社交的交易又是一套規則，將來 AI 普及之后，交易或許產生全新的規則。
如何提取規則呢？ 也需要從代碼中提取。
-
流程。首先，析取最通用的流程作為基礎；接着，再看有多出來的或剪裁的或者定制的。比如拼團訂單，從已支付到待發貨就多出來 待成團 到 已成團 的額外狀態流轉；比如虛擬商品，支付成功之后就立即變成已發貨，不經過待發貨。
-
判斷。從代碼中的各種 if-else-throw 可以提取出來。
提取規則之后，要仔細思考，為什么要定義這樣的規則，其背后的意圖和目標是什么？
語義####
構建了數據模型和規則之后，為了更好地擴展和發展系統的能力，需要對數據項及規則進行清晰無歧義的語義定義。有三類數據的語義要更加仔細：
- 狀態類語義。比如訂單狀態，通常涉及到業務的流轉過程，需要考慮可擴展性；當新增新的業務狀態時，能夠容易地支持。
- 金額類語義。比如應付金額和實付金額。如果缺乏清晰的語義，在多種業務交叉的情況下，金額類字段就可能有多種理解和取值，很容易導致資金的故障。而資金的故障通常是最嚴重的故障類別之一。
- 標識類語義。標識類字段用於唯一標識一個實體。
通過“數據模型+規則+語義”，可以勾勒出一個業務系統里的基本業務圖景。
項目實戰###
不下廚，永遠學不會做菜。
通過“數據模型+規則+語義”，可以獲得對業務的基本理解。不過這種理解往往是模糊不清晰的。通過項目實戰，推敲具體的業務實現細節，更深入地理解和擴展現有數據模型、規則、語義的含義及緣由。
對於具體業務，也可以采用這種思維框架來分析。只不過，這些都是基於通用部分而擴展出來的“數據模型+規則+語義”。
小結###
本文提出了理解業務的一種有效的思維框架：數據模型+規則+語義。通過“數據模型+規則+語義”，可以勾勒出一個業務系統里的基本業務圖景。不局限於工程代碼的實現，而是致力於從業務本身的數據、規則和語義去理解，更容易貼近業務真實的意圖和目標。