設計模式在外賣營銷業務中的實踐
一、前言
隨著美團外賣業務的不斷迭代與發展,外賣使用者數量也在高速地增長。在這個過程中,外賣營銷發揮了“中流砥柱”的作用,因為使用者的快速增長離不開高效的營銷策略。而由於市場環境和業務環境的多變,營銷策略往往是複雜多變的,營銷技術團隊作為營銷業務的支援部門,就需要快速高效地響應營銷策略變更帶來的需求變動。因此,設計並實現易於擴充套件和維護的營銷系統,是美團外賣營銷技術團隊不懈追求的目標和必修的基本功。
本文通過自頂向下的方式,來介紹設計模式如何幫助我們構建一套易擴充套件、易維護的營銷系統。本文會首先介紹設計模式與領域驅動設計(Domain-Driven Design,以下簡稱為DDD)之間的關係,然後再闡述外賣營銷業務引入業務中用到的設計模式以及其具體實踐案例。
二、設計模式與領域驅動設計
設計一個營銷系統,我們通常的做法是採用自頂向下的方式來解構業務,為此我們引入了DDD。從戰略層面上講,DDD能夠指導我們完成從問題空間到解決方案的剖析,將業務需求對映為領域上下文以及上下文間的對映關係。從戰術層面上,DDD能夠細化領域上下文,並形成有效的、細化的領域模型來指導工程實踐。建立領域模型的一個關鍵意義在於,能夠確保不斷擴充套件和變化的需求在領域模型內不斷地演進和發展,而不至於出現模型的腐化和領域邏輯的外溢。關於DDD的實踐,大家可以參考此前美團技術團隊推出的《領域驅動設計在網際網路業務開發中的實踐》一文。
同時,我們也需要在程式碼工程中貫徹和實現領域模型。因為程式碼工程是領域模型在工程實踐中的直觀體現,也是領域模型在技術層面的直接表述。而設計模式,可以說是連線領域模型與程式碼工程的一座橋樑,它能有效地解決從領域模型到程式碼工程的轉化。
為什麼說設計模式天然具備成為領域模型到程式碼工程之間橋樑的作用呢?其實,2003年出版的《領域驅動設計》一書的作者Eric Evans在這部開山之作中就已經給出瞭解釋。他認為,立場不同會影響人們如何看待什麼是“模式”。因此,無論是領域驅動模式還是設計模式,本質上都是“模式”,只是解決的問題不一樣。站在業務建模的立場上,DDD的模式解決的是如何進行領域建模。而站在程式碼實踐的立場上,設計模式主要關注於程式碼的設計與實現。既然本質都是模式,那麼它們天然就具有一定的共通之處。
所謂“模式”,就是一套反覆被人使用或驗證過的方法論。從抽象或者更巨集觀的角度上看,只要符合使用場景並且能解決實際問題,模式應該既可以應用在DDD中,也可以應用在設計模式中。事實上,Evans也是這麼做的。他在著作中闡述了Strategy和Composite這兩個傳統的GOF設計模式是如何來解決領域模型建設的。因此,當領域模型需要轉化為程式碼工程時,同構的模式,天然能夠將領域模型翻譯成程式碼模型。
三、設計模式在外賣營銷業務中的具體案例
3.1 為什麼需要設計模式
營銷業務的特點
如前文所述,營銷業務與交易等其他模式相對穩定的業務的區別在於,營銷需求會隨著市場、使用者、環境的不斷變化而進行調整。也正是因此,外賣營銷技術團隊選擇了DDD進行領域建模,並在適用的場景下,用設計模式在程式碼工程的層面上實踐和反映了領域模型。以此來做到在支援業務變化的同時,讓領域和程式碼模型健康演進,避免模型腐化。
理解設計模式
軟體設計模式(Design pattern),又稱設計模式,是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼,讓程式碼更容易被他人理解,保證程式碼可靠性,程式的重用性。可以理解為:“世上本來沒有設計模式,用的人多了,便總結出了一套設計模式。”
設計模式原則
面向物件的設計模式有七大基本原則:
- 開閉原則(Open Closed Principle,OCP)
- 單一職責原則(Single Responsibility Principle, SRP)
- 里氏代換原則(Liskov Substitution Principle,LSP)
- 依賴倒轉原則(Dependency Inversion Principle,DIP)
- 介面隔離原則(Interface Segregation Principle,ISP)
- 合成/聚合複用原則(Composite/Aggregate Reuse Principle,CARP)
- 最少知識原則(Least Knowledge Principle,LKP)或者迪米特法則(Law of Demeter,LOD)
簡單理解就是:開閉原則是總綱,它指導我們要對擴充套件開放,對修改關閉;單一職責原則指導我們實現類要職責單一;里氏替換原則指導我們不要破壞繼承體系;依賴倒置原則指導我們要面向介面程式設計;介面隔離原則指導我們在設計介面的時候要精簡單一;迪米特法則指導我們要降低耦合。
設計模式就是通過這七個原則,來指導我們如何做一個好的設計。但是設計模式不是一套“奇技淫巧”,它是一套方法論,一種高內聚、低耦合的設計思想。我們可以在此基礎上自由的發揮,甚至設計出自己的一套設計模式。
當然,學習設計模式或者是在工程中實踐設計模式,必須深入到某一個特定的業務場景中去,再結合對業務場景的理解和領域模型的建立,才能體會到設計模式思想的精髓。如果脫離具體的業務邏輯去學習或者使用設計模式,那是極其空洞的。接下來我們將通過外賣營銷業務的實踐,來探討如何用設計模式來實現可重用、易維護的程式碼。
3.2 “邀請下單”業務中設計模式的實踐
3.2.1 業務簡介
“邀請下單”是美團外賣使用者邀請其他使用者下單後給予獎勵的平臺。即使用者A邀請使用者B,並且使用者B在美團下單後,給予使用者A一定的現金獎勵(以下簡稱返獎)。同時為了協調成本與收益的關係,返獎會有多個計算策略。邀請下單後臺主要涉及兩個技術要點:
- 返獎金額的計算,涉及到不同的計算規則。
- 從邀請開始到返獎結束的整個流程。
3.2.2 返獎規則與設計模式實踐
業務建模
如圖是返獎規則計算的業務邏輯檢視:
從這份業務邏輯圖中可以看到返獎金額計算的規則。首先要根據使用者狀態確定使用者是否滿足返獎條件。如果滿足返獎條件,則繼續判斷當前使用者屬於新使用者還是老使用者,從而給予不同的獎勵方案。一共涉及以下幾種不同的獎勵方案:
新使用者
- 普通獎勵(給予固定金額的獎勵)
- 梯度獎(根據使用者邀請的人數給予不同的獎勵金額,邀請的人越多,獎勵金額越多)
老使用者
- 根據老使用者的使用者屬性來計算返獎金額。為了評估不同的邀新效果,老使用者返獎會存在多種返獎機制。
計算完獎勵金額以後,還需要更新使用者的獎金資訊,以及通知結算服務對使用者的金額進行結算。這兩個模組對於所有的獎勵來說都是一樣的。
可以看到,無論是何種使用者,對於整體返獎流程是不變的,唯一變化的是返獎規則。此處,我們可參考開閉原則,對於返獎流程保持封閉,對於可能擴充套件的返獎規則進行開放。我們將返獎規則抽象為返獎策略,即針對不同使用者型別的不同返獎方案,我們視為不同的返獎策略,不同的返獎策略會產生不同的返獎金額結果。
在我們的領域模型裡,返獎策略是一個值物件,我們通過工廠的方式生產針對不同使用者的獎勵策略值物件。下文我們將介紹以上領域模型的工程實現,即工廠模式和策略模式的實際應用。
模式:工廠模式
工廠模式又細分為工廠方法模式和抽象工廠模式,本文主要介紹工廠方法模式。
模式定義:定義一個用於建立物件的介面,讓子類決定例項化哪一個類。工廠方法是一個類的例項化延遲到其子類。
工廠模式通用類圖如下:
我們通過一段較為通用的程式碼來解釋如何使用工廠模式:
//抽象的產品
public abstract class Product {
public abstract void method();
}
//定義一個具體的產品 (可以定義多個具體的產品)
class ProductA extends Product {
@Override
public void method() {} //具體的執行邏輯
}
//抽象的工廠
abstract class Factory<T> {
abstract Product createProduct(Class<T> c);
}
//具體的工廠可以生產出相應的產品
class FactoryA extends Factory{
@Override
Product createProduct(Class c) {
Product product = (Product) Class.forName(c.getName()).newInstance();
return product;
}
}
模式:策略模式
模式定義:定義一系列演算法,將每個演算法都封裝起來,並且它們可以互換。策略模式是一種物件行為模式。
策略模式通用類圖如下:
我們通過一段比較通用的程式碼來解釋怎麼使用策略模式:
//定義一個策略介面
public interface Strategy {
void strategyImplementation();
}
//具體的策略實現(可以定義多個具體的策略實現)
public class StrategyA implements Strategy{
@Override
public void strategyImplementation() {
System.out.println("正在執行策略A");
}
}
//封裝策略,遮蔽高層模組對策略、演算法的直接訪問,遮蔽可能存在的策略變化
public class Context {
private Strategy strategy = null;
public Context(Strategy strategy) {
this.strategy = strategy;
}
public void doStrategy() {
strategy.strategyImplementation();
}
}
工程實踐
通過上文介紹的返獎業務模型,我們可以看到返獎的主流程就是選擇不同的返獎策略的過程,每個返獎策略都包括返獎金額計算、更新使用者獎金資訊、以及結算這三個步驟。 我們可以使用工廠模式生產出不同的策略,同時使用策略模式來進行不同的策略執行。首先確定我們需要生成出n種不同的返獎策略,其編碼如下:
//抽象策略
public abstract class RewardStrategy {
public abstract void reward(long userId);
public void insertRewardAndSettlement(long userId, int reward) {} ; //更新使用者資訊以及結算
}
//新使用者返獎具體策略A
public class newUserRewardStrategyA extends RewardStrategy {
@Override
public void reward(long userId) {} //具體的計算邏輯,...
}
//老使用者返獎具體策略A
public class OldUserRewardStrategyA extends RewardStrategy {
@Override
public void reward(long userId) {} //具體的計算邏輯,...
}
//抽象工廠
public abstract class StrategyFactory<T> {
abstract RewardStrategy createStrategy(Class<T> c);
}
//具體工廠建立具體的策略
public class FactorRewardStrategyFactory extends StrategyFactory {
@Override
RewardStrategy createStrategy(Class c) {
RewardStrategy product = null;
try {
product = (RewardStrategy) Class.forName(c.getName()).newInstance();
} catch (Exception e) {}
return product;
}
}
通過工廠模式生產出具體的策略之後,根據我們之前的介紹,很容易就可以想到使用策略模式來執行我們的策略。具體程式碼如下:
public class RewardContext {
private RewardStrategy strategy;
public RewardContext(RewardStrategy strategy) {
this.strategy = strategy;
}
public void doStrategy(long userId) {
int rewardMoney = strategy.reward(userId);
insertRewardAndSettlement(long userId, int reward) {
insertReward(userId, rewardMoney);
settlement(userId);
}
}
}
接下來我們將工廠模式和策略模式結合在一起,就完成了整個返獎的過程:
public class InviteRewardImpl {
//返獎主流程
public void sendReward(long userId) {
FactorRewardStrategyFactory strategyFactory = new FactorRewardStrategyFactory(); //建立工廠
Invitee invitee = getInviteeByUserId(userId); //根據使用者id查詢使用者資訊
if (invitee.userType == UserTypeEnum.NEW_USER) { //新使用者返獎策略
NewUserBasicReward newUserBasicReward = (NewUserBasicReward) strategyFactory.createStrategy(NewUserBasicReward.class);
RewardContext rewardContext = new RewardContext(newUserBasicReward);
rewardContext.doStrategy(userId); //執行返獎策略
}if(invitee.userType == UserTypeEnum.OLD_USER){} //老使用者返獎策略,...
}
}
工廠方法模式幫助我們直接產生一個具體的策略物件,策略模式幫助我們保證這些策略物件可以自由地切換而不需要改動其他邏輯,從而達到解耦的目的。通過這兩個模式的組合,當我們系統需要增加一種返獎策略時,只需要實現RewardStrategy介面即可,無需考慮其他的改動。當我們需要改變策略時,只要修改策略的類名即可。不僅增強了系統的可擴充套件性,避免了大量的條件判斷,而且從真正意義上達到了高內聚、低耦合的目的。
3.2.3 返獎流程與設計模式實踐
業務建模
當受邀人在接受邀請人的邀請並且下單後,返獎後臺接收到受邀人的下單記錄,此時邀請人也進入返獎流程。首先我們訂閱使用者訂單訊息並對訂單進行返獎規則校驗。例如,是否使用紅包下單,是否在紅包有效期內下單,訂單是否滿足一定的優惠金額等等條件。當滿足這些條件以後,我們將訂單資訊放入延遲佇列中進行後續處理。經過T+N天之後處理該延遲訊息,判斷使用者是否對該訂單進行了退款,如果未退款,對使用者進行返獎。若返獎失敗,後臺還有返獎補償流程,再次進行返獎。其流程如下圖所示:
我們對上述業務流程進行領域建模:
- 在接收到訂單訊息後,使用者進入待校驗狀態;
- 在校驗後,若校驗通過,使用者進入預返獎狀態,並放入延遲佇列。若校驗未通過,使用者進入不返獎狀態,結束流程;
- T+N天后,處理延遲訊息,若使用者未退款,進入待返獎狀態。若使用者退款,進入失敗狀態,結束流程;
- 執行返獎,若返獎成功,進入完成狀態,結束流程。若返獎不成功,進入待補償狀態;
- 待補償狀態的使用者會由任務定期觸發補償機制,直至返獎成功,進入完成狀態,保障流程結束。
可以看到,我們通過建模將返獎流程的多個步驟對映為系統的狀態。對於系統狀態的表述,DDD中常用到的概念是領域事件,另外也提及過事件溯源的實踐方案。當然,在設計模式中,也有一種能夠表述系統狀態的程式碼模型,那就是狀態模式。在邀請下單系統中,我們的主要流程是返獎。對於返獎,每一個狀態要進行的動作和操作都是不同的。因此,使用狀態模式,能夠幫助我們對系統狀態以及狀態間的流轉進行統一的管理和擴充套件。
模式:狀態模式
模式定義:當一個物件內在狀態改變時允許其改變行為,這個物件看起來像改變了其類。
狀態模式的通用類圖如下圖所示:
對比策略模式的型別會發現和狀態模式的類圖很類似,但實際上有很大的區別,具體體現在concrete class上。策略模式通過Context產生唯一一個ConcreteStrategy作用於程式碼中,而狀態模式則是通過context組織多個ConcreteState形成一個狀態轉換圖來實現業務邏輯。接下來,我們通過一段通用程式碼來解釋怎麼使用狀態模式:
//定義一個抽象的狀態類
public abstract class State {
Context context;
public void setContext(Context context) {
this.context = context;
}
public abstract void handle1();
public abstract void handle2();
}
//定義狀態A
public class ConcreteStateA extends State {
@Override
public void handle1() {} //本狀態下必須要處理的事情
@Override
public void handle2() {
super.context.setCurrentState(Context.contreteStateB); //切換到狀態B
super.context.handle2(); //執行狀態B的任務
}
}
//定義狀態B
public class ConcreteStateB extends State {
@Override
public void handle2() {} //本狀態下必須要處理的事情,...
@Override
public void handle1() {
super.context.setCurrentState(Context.contreteStateA); //切換到狀態A
super.context.handle1(); //執行狀態A的任務
}
}
//定義一個上下文管理環境
public class Context {
public final static ConcreteStateA contreteStateA = new ConcreteStateA();
public final static ConcreteStateB contreteStateB = new ConcreteStateB();
private State CurrentState;
public State getCurrentState() {return CurrentState;}
public void setCurrentState(State currentState) {
this.CurrentState = currentState;
this.CurrentState.setContext(this);
}
public void