架構設計之三種業務模型：活動資源模型、契約模型、模闆模型

1 文章概述

在實際開發場景中業務需求各式各樣，在技術方案設計階段，架構師的工作就是将業務語言翻譯為技術語言。

雖然業務場景多種多樣，但是架構師需要發現不同業務相通之處，抽象成通用模型，這樣後續再遇到需求，即使業務場景大相徑庭，也可以使用同一套模型應對。本文分析三種業務模型：

• 活動資源模型
• 契約模型
• 模闆模型

2 活動資源模型

2.1 業務場景

商家A總共準備發放一種滿100減10元優惠券100張，商家A有5家店鋪，每個店鋪優惠券發放規則各不相同：

• 店鋪1：每人限領1張
• 店鋪2：每人限領2張
• 店鋪3：隻允許A城市使用者領券
• 店鋪4：隻允許新使用者領券
• 店鋪5：隻允許B城市C區中老使用者領券

2.2 模型分析

2.2.1 資源

各個店鋪發放優惠券規則完全不同，但是優惠券隻有一種，是以不可能将規則沉澱在優惠券，這就引出本文第一種模型：活動資源模型。優惠券作為一種資源，隻承載資源最本質屬性：

• 發放張數
• 優惠類型（滿減/滿折）
• 優惠金額
• 折扣比例
• 使用門檻金額
• 有效期

發放張數屬性控制資源總成本，需要仔細評估。

2.2.2 活動

那麼店鋪不同的發放規則在哪裡展現？答案是活動領域。每個店鋪可以根據經營政策，設定本店鋪營銷活動和不同活動規則，本例中各個店鋪可以設定各種活動規則，但是共享同一份資源（100張優惠券），常見活動規則：

• 活動開始時間
• 活動截止時間
• 資源領取類型（系統發放/手動領取）
• 每人允許參與活動次數
• 允許參與使用者規則
• 允許參與城市規則
• 允許參與商品規則
• 活動資源規則：每人允許領取X張資源

2.3 資料模型

2.3.1 資源相關

• 優惠券表
• 資源本質資訊
• 優惠券領取流水表
• 資源領取記錄
• 優惠券使用流水表
• 資源使用記錄
• 優惠券使用明細表
• 訂單使用資源優惠明細

2.3.2 活動相關

• 活動表
• 活動本質資訊
• 活動資源規則表
• 每個人允許領取X張資源
• 活動地區規則表
• 允許參與活動地區資訊
• 活動使用者規則表
• 允許參與活動使用者資訊
• 活動商品規則表
• 允許參與活動商品資訊

3 契約模型

3.1 業務場景

商品A每個5元，使用者購買3個并下單成功，但是還沒有付款。此時賣家對商品價格做出調整改為每個100元，那麼使用者應該付15元還是300元？

3.2 模型分析

訂單本質上是一種契約，一旦簽訂（下單）核心資訊就不允許更改。當時使用者簽訂契約是每個5元，即使後續調整為每個100元，也不應該影響已簽訂契約。

既然契約具有不可變性，那麼契約對象就要儲存簽訂瞬間各類快照資訊，訂單就是一種非常典型的契約對象。

3.3 資料模型

本章節以訂單模型為例介紹契約模型，這種模型特點是集各類快照之大成，所有涉及資訊都要記錄。

3.3.1基本資訊

• 訂單編号
• 業務類型
• 下單管道
• 下單時間
• 訂單狀态
• 商家Id
• 店鋪Id
• 下單使用者Id

3.3.2 支付與促銷資訊

• 支付方式（支付寶/微信/銀行卡）
• 支付單号
• 支付賬戶
• 應付金額
• 實付金額
• 使用優惠券Id
• 優惠券抵扣金額
• 使用者權益抵扣金額
• 參與促銷活動Id
• 營銷活動抵扣金額
• 運費金額

3.3.3 物流資訊

• 配送方式（物流/同城/自提）
• 配送公司
• 收貨省、市、區
• 收貨詳細位址
• 收貨人電話
• 快遞單号
• 自提省市區
• 自提詳細位址
• 自提商家電話

3.3.4 商品明細

• 子訂單Id
• 子訂單狀态
• skuId
• skuTitle
• 購買數量
• 銷售單價
• 實付單價
• 實付總金額
• 分攤優惠券金額
• 分攤使用者權益金額
• 分攤促銷活動金額

3.4 漫長的流程

契約模型要記錄如此多的快照資訊，意味着契約系統要和很多系統互動，例如在使用優惠券時，訂單系統要詢問優惠券系統能不能用優惠券。在使用者支付時需要與支付系統互動，并等待支付系統回調。在使用者支付完成15分鐘後将訂單下推至排程中心，進行發貨排程。這也就意味着契約系統複雜度要比一般系統高。銷售層訂單一般流程：

• 使用者下單
• 風控校驗
• 擷取商品資訊
• 限購校驗
• 擷取優惠券
• 擷取促銷活動
• 擷取使用者權益
• 鎖定庫存（排程中心）
• 計算運費（物流系統）
• 生成不可見訂單
• 扣減庫存
• 扣減優惠券
• 扣減使用者權益
• 占用活動資格
• 訂單可見（待支付）
• 支付訂單（已支付）
• 訂單下推
• 物流發貨
• 使用者簽收（已完成）
• 使用者評價

4 模闆模型

4.1 業務場景

商家可以設定不同城市的運費模闆：

• A城市：按件數計費
• 首重：2件
• 首費：1元
• 續重：1件
• 續費：1元
• B城市：按重量計費
• 首重：3公斤
• 首費：1元
• 續重：2公斤
• 續費：1元

商家可以将商品與運費模闆綁定，購買商品時讀取運費模闆計算運費

4.2 模型分析

模闆作用是定義規則，模闆模型的作用是将業務對象與規則解耦，規則定義在模闆，再與業務對象綁定。這樣做有兩個有點：第一是規則與業務對象解耦，第二是模闆可以複用，相同規則不用重複設定。

我們可以對比模闆模型與契約模型，契約模型是一旦簽訂，無論契約中原始資料如何變化，都不會改變契約。但是模闆模型，業務對象在形成契約之前，需要實時感覺模闆内容變化，例如在下單前，商品綁定的運費模闆續費調整了，需要重新計算價格。

4.3 資料模型

• 模闆表
• 定義規則
• 業務對象與模闆關系表
• 建立業務對象與模闆關系

5 文章總結

在設計技術方案時雖然需求表面各式各樣，作為架構師需要思考能否抽取共通之處，本文介紹了三種常見的業務模型：活動資源模型、契約模型、模闆模型。

活動資源模型中資源隻設定本資源最本質的屬性，活動靈活控制規則。契約模型中一旦契約簽訂不允許再改變，這也意味着契約需要記錄大而全的資訊。模闆模型中模闆定義規則，業務對象綁定模闆，并且需要實時感覺模闆變化。