•  左側為享受促銷的資格，常見為這三種：

  • 首單

  • 大於或等於某個會員級別

  • 特定會員組：比如女性，月消費滿1000等等，都是通過查詢條件查詢出來的特定分組。

• 優惠型別，對於電商網站主要是下面4類：

  • 金額

  • 贈品：商品、優惠券、現金券、積分等

  • 包郵（實際上也是錢）

  • 其它：如送精美包裝等。 對於其它業務型別的平臺，則估計會有其它形式的優惠，比如贈送三個VIP會員等等。

• 範圍，無非就是：

  • 整單

  • 指定品類或特定品類（臨時的活動分類，比如夏季新品特賣）

  • 指定商品

• 滿減：針對金額的減免，可以指定金額或百分比，涉及階梯累加和數量累加等。

• 滿贈：滿足條件後獲得贈品，贈品可以是五花八門，對於電商平臺一般是商品、現金券、優惠券、積分等。

• 包郵：金額減免的另一種方式，但效果比減免小額金額要好。

• 其它規則：有些會帶來設計的複雜度，但本質無非就是滿減或滿贈。

2促 銷 的 表 現 形 式

    促銷的表現形式主要分為促銷活動和優惠券兩種。

    站在系統的角度，促銷活動是主動的，優惠券是被動的。

    促銷活動表示只要滿足條件，下單時自動會進行促銷規則計算，進行減免或者贈送。但是優惠券必須客戶進行選擇（或者輸入券碼）。

    促銷活動可以多個同時生效，比如：

• 首單包郵

• 滿100減20

• 買電磁爐贈送餐具

    這三個促銷活動對於新會員（未曾購買過）都是同時有效的。

    但促銷活動存在互斥和優先順序，這兩個概念在後面再分析。

    優惠券只存在一張優惠券生效。

    即客戶選擇使用哪一張，就哪一張生效，無所謂互斥或者優先順序。

    優惠券可以和促銷活動同時生效，只要生效促銷活動不排斥優惠券即可。

    那麼，對於促銷規則而言，促銷活動和優惠券只是它上層的表現形式，實際的底層的促銷規則是可以共用的（無非都是滿減、滿贈）

3促 銷 規 則 分 析

    從第一節場景來看，促銷無非就是看：

1.  是否滿足資格

   1. 沒有資格享受該優惠，就不必往下計算了。

2.   當前規則的優惠型別是什麼？

   1. 滿減、滿贈、包郵或者其它？

3.  當前規則的生效範圍是什麼？

   1. 判斷客戶當前訂單（購物車）是否滿足當前規則生效範圍之內，是則計算優惠。

4. 規則的累加規則是什麼？

   1. 階梯累加：一般只針對金額

   2. 數量累加：否則只計算一次，是則乘以倍數。

5. 規則之間的關係是怎樣的？

   1. 優先順序

   2. 相容

   3. 互斥

    可以通過這張圖整體理解這個結構：

4促 銷 規 則 的 關 系

    促銷規則的關係是設計的一個難點，對於規則而言本身是獨立的，所以所謂關係就是它的上層表現形式的關係，而前面第二節也談到，優惠券之間是無所謂關係的，用那張就那張生效（前提是該張優惠券可用，可以用）。

    那麼現在要分析的關係就只有：

• 促銷活動之間的關係

• 促銷活動和優惠券之間的關係

    其中促銷活動與優惠券的關係是一票否決方式，即只要本次訂單（購物車）對應的生效促銷活動有任一個設定為：排斥優惠券，則本訂單（購物車）不能使用優惠券。

    那麼我們剩下要分析的就是促銷活動之間的關係了，詳見下圖：

5領 域 業 務 建 模（模組級別）

1. 促銷規則獨立為一個模組

   1. 促銷活動、優惠券的管理在模組內，共規則模型呼叫。

   2. 規則模型對外提供介面，其它模組只能通過該介面訪問模型。

   3. 模型實現該介面。

   4. 規則介面要求傳入上下文引數

   5. 該上下文引數包含：商品列表（購物車當前選擇的商品，客戶ID 和 使用的優惠券。

   6. 規則介面是規則模組的邊界。

2. 呼叫者為購物車模組。

   1. 任何時候購物車發生修改時，呼叫規則介面重新計算。

   2. 規則發生更改時，會發送事件出來。

   3. 購物車模組計算價格業務監聽此事件，有變更則更新相關購物車的價格。

   4. 此監聽器為非同步。

3. 外部支援介面

   1. 客戶介面：供查詢客戶資格相關使用

   2. 商品介面：供查詢商品分類和其它定義使用。

6領 域 業 務 建 模（類級別）

    類圖有些大，手機上如果看不清，可以分享到pc上檢視。

    設計思路過程描述：

1. 1.  提供CartRuleService作為對外介面

   2. 分別呼叫：

      1. PromotionService：促銷活動介面

      2. CouponService：優惠券介面

來處理促銷活動和優惠券。

1. 促銷活動介面和優惠券介面均是實際呼叫RuleService來實現促銷規則計算。

2. RuleService的實現採用橋模式和策略模式，並通過工程模式獲得各個策略的例項。

3. 傳入的上下文引數封裝為RuleContext，傳給RuleService

4. RuleService返回RuleResult物件

5. PromotionResult和CoupontResult分別封裝RuleResult物件進行返回。

    通過這個設計方案，當有新的資格判斷方式、目標範圍和優惠型別時，通過新增策略實現即可，符合開閉原則。

7規 則 的 持 久 化

    前面已經充分分析了規則的各個內容，如何將促銷活動、優惠券和促銷規則持久化以及持久化儲存到那裡其實已經是水到渠成的事情。怎樣儲存其實都可以，哪怕是一個json結構。

    因為無論什麼結構，最終在程式碼中都會被解析為物件並快取起來供介面實現來呼叫。所以資料庫設計在效率上不會要求太高。

    資料庫結構ER圖：

1.  規則定義和規則利益是獨立的兩個表，和優惠券、促銷活動一對一關聯。

2. 規則定義包含：

   1. 資格型別、資格配置

   2. 利益型別、利益引數（是否累加）

   3. 目標範圍型別、範圍設定

   4. 其它欄位根據專案情況自由新增。

3. 規則利益

   1. 可以對不同的利益分別設計欄位。

   2. 也可以設定一個利益型別和利益配置（json結構）

   3. 之所以獨立出來作為子表，是因為存在階梯累加的業務情況需要配置多條利益。

4. 優惠券的設計為常規方式

   1. 定義：定義它的各種引數

   2. 實體：具體某一張優惠券

   3. 使用：一般一張優惠券只會使用一次，記錄使用歷史，也有優惠券可以使用多次。   

5. 促銷活動定義

   1. 前面第4節說的促銷規則的關係（其實是促銷活動的關係）就是定義在這裡。

   2. 分組、優先順序、對優惠券的排斥等。

6. 促銷活動的參與日誌

   1. 記錄誰參與過

   2. 有些促銷活動只能參與一次，則通過此表判斷。