Java生鮮電商平台-電商促銷業務分析設計與系統架構

Java生鮮電商平台-電商促銷業務分析設計與系統架構

 

說明：Java開源生鮮電商平台-電商促銷業務分析設計與系統架構,列舉的是常見的促銷場景與源代碼下載

 

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

• 首單

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

• 特定會員組：比如女性，月消費滿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.  提供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. 有些促銷活動只能參與一次，則通過此表判斷。