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. 有些促銷活動只能參與一次，則經過此表判斷。