了解業務的思維架構：資料模型+規則+語義

本文提出了了解業務的一種有效的思維架構：資料模型+規則+語義。

規則是流動的。 網際網路的美妙，在于可以重構規則，進而革新現有的一切。

概述

中大型業務系統中，往往多種業務互相交叉，錯綜複雜，使得系統變得難以了解。一般的方法是，通過閱讀工程代碼來了解系統。但這種方法是有局限性的。因為工程代碼，往往是系統設計實作與業務的混合體，并不完全一緻地表達着業務本身：

• 由于當時的技術和系統架構的限制，往往實作的并不是最優的業務視角，而是折衷過的；
• 部分代碼寫得比較蹩腳，表達不準确，甚至有 BUG ，反而妨礙真正了解業務本身。

要真正了解業務，需要從業務本身上去了解，嚴格區分出“業務規則”與“系統設計與實作”這兩個不同的層面。工程代碼，可以作為重要的參考。

三要素

資料模型

資料模型指的是，需要哪些資料項，資料項之間的關聯，如何有序地組織這些資料項。資料模型是軟體整體設計的導航圖。确定良好的資料模型，設計就成功了一大半。

比如交易的基本資料模型如下。通過這個模型，可以全局式地概覽交易所涉及到的各種基本資料、各個基礎子產品，有一個整體而基本的把握。

針對具體業務，則可更容易地了解和分析。具體業務的資料模型，通常是基礎資料模型再加上一些擴充性的資料集。

如何提煉資料模型呢 ？

可以從工程代碼裡的各種 DO，DTO ，服務接口傳回的資料對象入手。推敲每個字段的含義，将其進行歸類。這時候，采用的是有選擇性地閱讀，閱讀代碼呈現的關鍵對象，而不是在荊棘叢生的代碼中穿梭，弄的遍體鱗傷。

規則

規則指的是，資料項及流程要滿足什麼限制 ？為了什麼目标而服務 ？

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

下單流程還可以擴充得更完整一些：進入店鋪 -> 點選商詳頁 -> 跳轉訂單确認頁 -> 送出訂單 -> 支付 -> 跳轉訂單支付結果頁。這個流程涉及更多的基礎服務，比如店鋪、商品、支付、優惠、物流、會員等。

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

除了流程，規則也指資料項之間的限制。 比如 價格、優惠之間的計算公式，退款校驗，不支援的場景等。

關于規則最重要的一個觀點是：規則是流動的。 不要拘泥于現有的規則。完全可以建立新的規則。 比如線上交易是一套規則，線下交易又是一套規則，基于社交的交易又是一套規則，将來 AI 普及之後，交易或許産生全新的規則。

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

• 流程。首先，析取最通用的流程作為基礎；接着，再看有多出來的或剪裁的或者定制的。比如拼團訂單，從已支付到待發貨就多出來 待成團 到 已成團 的額外狀态流轉；比如虛拟商品，支付成功之後就立即變成已發貨，不經過待發貨。
• 判斷。從代碼中的各種 if-else-throw 可以提取出來。

提取規則之後，要仔細思考，為什麼要定義這樣的規則，其背後的意圖和目标是什麼？

語義

建構了資料模型和規則之後，為了更好地擴充和發展系統的能力，需要對資料項及規則進行清晰無歧義的語義定義。有三類資料的語義要更加仔細：

• 狀态類語義。比如訂單狀态，通常涉及到業務的流轉過程，需要考慮可擴充性；當新增新的業務狀态時，能夠容易地支援。
• 金額類語義。比如應付金額和實付金額。如果缺乏清晰的語義，在多種業務交叉的情況下，金額類字段就可能有多種了解和取值，很容易導緻資金的故障。而資金的故障通常是最嚴重的故障類别之一。
• 辨別類語義。辨別類字段用于唯一辨別一個實體。

通過“資料模型+規則+語義”，可以勾勒出一個業務系統裡的基本業務圖景。

項目實戰

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

通過“資料模型+規則+語義”，可以獲得對業務的基本了解。不過這種了解往往是模糊不清晰的。通過項目實戰，推敲具體的業務實作細節，更深入地了解和擴充現有資料模型、規則、語義的含義及緣由。

對于具體業務，也可以采用這種思維架構來分析。隻不過，這些都是基于通用部分而擴充出來的“資料模型+規則+語義”。

小結

本文提出了了解業務的一種有效的思維架構：資料模型+規則+語義。通過“資料模型+規則+語義”，可以勾勒出一個業務系統裡的基本業務圖景。不局限于工程代碼的實作，而是緻力于從業務本身的資料、規則和語義去了解，更容易貼近業務真實的意圖和目标。