前言 去年供職於一家電商公司，被分配到做商城營銷體系的開發設計。本文章記錄了我這個小菜鳥在營銷設計中遇到的坑坑窪窪，以及在重構中的思路。 線性思維，線性設計 首先我們列一列營銷組件有哪些 。 滿減 折扣 秒殺 組合購 換購 優惠券 新人有禮 邀請有禮 簽到 紅包裂變 ... 其次是要知道營銷在 正向 ...
前言
去年供職於一家電商公司，被分配到做商城營銷體系的開發設計。本文章記錄了我這個小菜鳥在營銷設計中遇到的坑坑窪窪，以及在重構中的思路。
線性思維，線性設計
首先我們列一列營銷組件有哪些。
- 滿減
- 折扣
- 秒殺
- 組合購
- 換購
- 優惠券
- 新人有禮
- 邀請有禮
- 簽到
- 紅包裂變
- ...
其次是要知道營銷在正向流程，即用戶的下單路徑中營銷系統是如何起作用的，當然這隻是簡單的示意圖，實際業務中要複雜許多。
在這種情況下我選擇了一種“理所應當的設計”，即一種組件對應一個微服務。當然LZ不是說這種設計很糟糕，在營銷需求不多的情況下這種方式能最快出成果。
其實在營銷組件很多的情況下組件、服務一對一的設計仍有優點，因為符合開閉原則，需求變更再頻繁，也只需對單個組件進行更改，不影響其他組件的正常工作。
實際上在下游與營銷組件之間我會加一層聚合服務，用來收縮營銷的邊界，統一提供如計價、優惠顯示等能力，避免給系統加入過多的耦合關係。
這種線性的服務設計能在迭代初期解決大部分問題，但暴露出來的問題也是顯而易見的：
- 部署成本較高
- 代碼庫大量duplicate code，且組件之間的表設計有60%-70%相近
- 一些重要的主流程邏輯其複雜度會隨著組件數量提升而提升，且嚴重依賴於單應用的響應時間，無法降級
重構：凡事都得按‘規則’來
在接受線性設計所帶來的弊端後，我著手開始重構工作。不得不說這是個困難的工程，淘寶花了十年，經歷6次重構，才實現了不上線就可以加組件，不得不說還是NB。
重構的方向：：抽取共性，合併工程，組件不決定服務。
從業務中來，還得回到業務中去，和PM零零散散地歸納了現有營銷業務的一些特點，以及將來的需求趨向。可以將現有營銷十幾種組件歸為三類。
像積分權益、團購、優惠券等後置的營銷活動，屬於邊界清晰、較為獨立的服務，暫時不納入重構的範圍。這次討論的是改價類和組合類這兩種前置營銷，即在結算前發生的營銷活動。
改價類：針對單品進行改價，在購物車中直接顯示活動價格。
組合類：針對多個商品進行改價，前置條件是1-n個商品通過數量/價格/sku類型 等觸發的優惠，優惠形式也有多種: 直減/贈品/N元換購。
雖然分為兩類，但這些組件最終的效果都是改變訂單中的物品價格，改價類比較直觀，而贈品和N元換購同樣可以視為將某個商品自動加入到訂單中，並對其改價的行為。
除了這點，組件們也有很多相同的屬性，如生效時間段、限購、面對的用戶群體、生效的sku範圍等等。
新設計
面向對象的設計：所有依賴關係都終止於抽象類與抽象介面。
OOP的精神無處不可借鑒。在瞭解到這些共性之後，我們就可以抽象出自己的通用規則模型了，說到模型~~其實像營銷體系這類複雜度較高的系統，實踐DDD是個不錯的選擇~
在新的設計中，引入規則的概念。如果營銷是類，那麼規則就是這個類的一個實例。一條規則會擁有若幹欄位，按組分類之：
前置條件
- 用戶資格
- 目標範圍
- 門檻量
- 限購額度
- 生效時間
- ...
優惠參數
- 優惠方式
- 優惠內容
- ...
規格
- 優先順序
- 類型
- ...
前置條件決定瞭如何觸發這條規則;
優惠參數決定了觸發後如何針對訂單改價；
規格決定了這條規則的其他屬性：
優先順序用來控制規則之間的計算順序；類型決定了這條規則的業務類型，也就是它代表的是什麼組件，用於分組、互斥和觸發組件的特有行為。
建表欄位自然也就按以上來參考，基本是一一對應，當然最好是預留一些欄位。不要高估自己的抽象能力，何況你永遠不知道下一個需求有多“驚喜”。必要時也可以建立規則詳情表，容納更多的可能性，總是好的~
建立好規則表，其他相關的業務表也手到擒來了，如商品關聯表，優惠記錄表等等，這一塊的共性很多，設計起來比較自由，就不贅述了，做好和規則記錄的關聯即可。
在此基礎上，就可以開始重構業務模塊了，對於一些CURD介面無非就是把庫都集中挪到同一個地方了，比較簡單。難點在於計價模塊，如何通過規則類型來區別化表達這張規則表，從而各種營銷玩法都能準確完成價格計算，這裡我採用了註解驅動的策略模式。實現等到下次在講~
排版不是很好，慢慢進步，peace~
