設計模式在美團外賣營銷業務中的實踐

一、前言

隨著美團外賣業務的不斷迭代與發展，外賣使用者數量也在高速地增長。在這個過程中，外賣營銷發揮了“中流砥柱”的作用，因為使用者的快速增長離不開高效的營銷策略。而由於市場環境和業務環境的多變，營銷策略往往是複雜多變的，營銷技術團隊作為營銷業務的支援部門，就需要快速高效地響應營銷策略變更帶來的需求變動。因此，設計並實現易於擴充套件和維護的營銷系統，是美團外賣營銷技術團隊不懈追求的目標和必修的基本功。

本文通過自頂向下的方式，來介紹設計模式如何幫助我們構建一套易擴充套件、易維護的營銷系統。本文會首先介紹設計模式與領域驅動設計（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一定的現金獎勵（以下簡稱返獎）。同時為了協調成本與收益的關係，返獎會有多個計算策略。邀請下單後臺主要涉及兩個技術要點：

1. 返獎金額的計算，涉及到不同的計算規則。
2. 從邀請開始到返獎結束的整個流程。

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天之後處理該延遲訊息，判斷使用者是否對該訂單進行了退款，如果未退款，對使用者進行返獎。若返獎失敗，後臺還有返獎補償流程，再次進行返獎。其流程如下圖所示：

我們對上述業務流程進行領域建模：

1. 在接收到訂單訊息後，使用者進入待校驗狀態；
2. 在校驗後，若校驗通過，使用者進入預返獎狀態，並放入延遲佇列。若校驗未通過，使用者進入不返獎狀態，結束流程；
3. T+N天后，處理延遲訊息，若使用者未退款，進入待返獎狀態。若使用者退款，進入失敗狀態，結束流程；
4. 執行返獎，若返獎成功，進入完成狀態，結束流程。若返獎不成功，進入待補償狀態；
5. 待補償狀態的使用者會由任務定期觸發補償機制，直至返獎成功，進入完成狀態，保障流程結束。

可以看到，我們通過建模將返獎流程的多個步驟對映為系統的狀態。對於系統狀態的表述，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 handle1() {this.CurrentState.handle1();}
    public void handle2() {this.CurrentState.handle2();}
}
//定義client執行
public class client {
    public static void main(String[] args) {
        Context context = new Context();
        context.setCurrentState(new ContreteStateA());
        context.handle1();
        context.handle2();
    }
}
複製程式碼

工程實踐

通過前文對狀態模式的簡介，我們可以看到當狀態之間的轉換在不是非常複雜的情況下，通用的狀態模式存在大量的與狀態無關的動作從而產生大量的無用程式碼。在我們的實踐中，一個狀態的下游不會涉及特別多的狀態裝換，所以我們簡化了狀態模式。當前的狀態只負責當前狀態要處理的事情，狀態的流轉則由第三方類負責。其實踐程式碼如下：

//返獎狀態執行的上下文
public class RewardStateContext {
​
    private RewardState rewardState;
  
    public void setRewardState(RewardState currentState) {this.rewardState = currentState;}
    public RewardState getRewardState() {return rewardState;}
    public void echo(RewardStateContext context, Request request) {
        rewardState.doReward(context, request);
    }
}
​
public abstract class RewardState {
    abstract void doReward(RewardStateContext context, Request request);
}
​
//待校驗狀態
public class OrderCheckState extends RewardState {
    @Override
    public void doReward(RewardStateContext context, Request request) {
        orderCheck(context, request);  //對進來的訂單進行校驗，判斷是否用券，是否滿足優惠條件等等
    }
}
​
//待補償狀態
public class CompensateRewardState extends RewardState {
    @Override
    public void doReward(RewardStateContext context, Request request) {
        compensateReward(context, request);  //返獎失敗，需要對使用者進行返獎補償
    }
}
​
//預返獎狀態，待返獎狀態，成功狀態，失敗狀態(此處邏輯省略)
//..
​
public class InviteRewardServiceImpl {
    public boolean sendRewardForInvtee(long userId, long orderId) {
        Request request = new Request(userId, orderId);
        RewardStateContext rewardContext = new RewardStateContext();
        rewardContext.setRewardState(new OrderCheckState());
        rewardContext.echo(rewardContext, request);  //開始返獎，訂單校驗
        //此處的if-else邏輯只是為了表達狀態的轉換過程，並非實際的業務邏輯
        if (rewardContext.isResultFlag()) {  //如果訂單校驗成功，進入預返獎狀態
            rewardContext.setRewardState(new BeforeRewardCheckState());
            rewardContext.echo(rewardContext, request);
        } else {//如果訂單校驗失敗，進入返獎失敗流程，...
            rewardContext.setRewardState(new RewardFailedState());
            rewardContext.echo(rewardContext, request);
            return false;
        }
        if (rewardContext.isResultFlag()) {//預返獎檢查成功，進入待返獎流程，...
            rewardContext.setRewardState(new SendRewardState());
            rewardContext.echo(rewardContext, request);
        } else {  //如果預返獎檢查失敗，進入返獎失敗流程，...
            rewardContext.setRewardState(new RewardFailedState());
            rewardContext.echo(rewardContext, request);
            return false;
        }
        if (rewardContext.isResultFlag()) {  //返獎成功，進入返獎結束流程，...
            rewardContext.setRewardState(new RewardSuccessState());
            rewardContext.echo(rewardContext, request);
        } else {  //返獎失敗，進入返獎補償階段，...
            rewardContext.setRewardState(new CompensateRewardState());
            rewardContext.echo(rewardContext, request);
        }
        if (rewardContext.isResultFlag()) {  //補償成功，進入返獎完成階段，...
            rewardContext.setRewardState(new RewardSuccessState());
            rewardContext.echo(rewardContext, request);
        } else {  //補償失敗，仍然停留在當前態，直至補償成功（或多次補償失敗後人工介入處理）
            rewardContext.setRewardState(new CompensateRewardState());
            rewardContext.echo(rewardContext, request);
        }
        return true;
    }
}
複製程式碼

狀態模式的核心是封裝，將狀態以及狀態轉換邏輯封裝到類的內部來實現，也很好的體現了“開閉原則”和“單一職責原則”。每一個狀態都是一個子類，不管是修改還是增加狀態，只需要修改或者增加一個子類即可。在我們的應用場景中，狀態數量以及狀態轉換遠比上述例子複雜，通過“狀態模式”避免了大量的if-else程式碼，讓我們的邏輯變得更加清晰。同時由於狀態模式的良好的封裝性以及遵循的設計原則，讓我們在複雜的業務場景中，能夠遊刃有餘地管理各個狀態。

3.3 點評外賣投放系統中設計模式的實踐

3.3.1 業務簡介

繼續舉例，點評App的外賣頻道中會預留多個資源位為營銷使用，向使用者展示一些比較精品美味的外賣食品，為了增加使用者點外賣的意向。當使用者點選點評首頁的“美團外賣”入口時，資源位開始載入，會通過一些規則來篩選出合適的展示Banner。

3.3.2 設計模式實踐

業務建模

對於投放業務，就是要在這些資源位中展示符合當前使用者的資源。其流程如下圖所示：

從流程中我們可以看到，首先運營人員會配置需要展示的資源，以及對資源進行過濾的規則。我們資源的過濾規則相對靈活多變，這裡體現為三點：

1. 過濾規則大部分可重用，但也會有擴充套件和變更。
2. 不同資源位的過濾規則和過濾順序是不同的。
3. 同一個資源位由於業務所處的不同階段，過濾規則可能不同。

過濾規則本身是一個個的值物件，我們通過領域服務的方式，操作這些規則值物件完成資源位的過濾邏輯。下圖介紹了資源位在進行使用者特徵相關規則過濾時的過程：

為了實現過濾規則的解耦，對單個規則值物件的修改封閉，並對規則集合組成的過濾鏈條開放，我們在資源位過濾的領域服務中引入了責任鏈模式。

模式：責任鏈模式

模式定義：使多個物件都有機會處理請求，從而避免了請求的傳送者和接受者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有物件處理它為止。

責任鏈模式通用類圖如下：

我們通過一段比較通用的程式碼來解釋如何使用責任鏈模式：

//定義一個抽象的handle
public abstract class Handler {
    private Handler nextHandler;  //指向下一個處理者
    private int level;  //處理者能夠處理的級別
​
    public Handler(int level) {
        this.level = level;
    }
​
    public void setNextHandler(Handler handler) {
        this.nextHandler = handler;
    }
​
    // 處理請求傳遞，注意final，子類不可重寫
    public final void handleMessage(Request request) {
        if (level == request.getRequstLevel()) {
            this.echo(request);
        } else {
            if (this.nextHandler != null) {
                this.nextHandler.handleMessage(request);
            } else {
                System.out.println("已經到最盡頭了");
            }
        }
    }
    // 抽象方法，子類實現
    public abstract void echo(Request request);
}
​
// 定義一個具體的handleA
public class HandleRuleA extends Handler {
    public HandleRuleA(int level) {
        super(level);
    }
    @Override
    public void echo(Request request) {
        System.out.println("我是處理者1,我正在處理A規則");
    }
}
​
//定義一個具體的handleB
public class HandleRuleB extends Handler {}  //...
​
//客戶端實現
class Client {
    public static void main(String[] args) {
        HandleRuleA handleRuleA = new HandleRuleA(1);
        HandleRuleB handleRuleB = new HandleRuleB(2);
        handleRuleA.setNextHandler(handleRuleB);  //這是重點，將handleA和handleB串起來
        handleRuleA.echo(new Request());
    }
}
複製程式碼

​ 工程實踐

下面通過程式碼向大家展示如何實現這一套流程：

//定義一個抽象的規則
public abstract class BasicRule<CORE_ITEM, T extends RuleContext<CORE_ITEM>>{
    //有兩個方法，evaluate用於判斷是否經過規則執行，execute用於執行具體的規則內容。
    public abstract boolean evaluate(T context);
    public abstract void execute(T context) {
}
​
//定義所有的規則具體實現
//規則1：判斷服務可用性
public class ServiceAvailableRule extends BasicRule<UserPortrait, UserPortraitRuleContext> {
    @Override
    public boolean evaluate(UserPortraitRuleContext context) {
        TakeawayUserPortraitBasicInfo basicInfo = context.getBasicInfo();
        if (basicInfo.isServiceFail()) {
              return false;
        }
        return true;
    }
  
    @Override
    public void execute(UserPortraitRuleContext context) {}
​
}
//規則2：判斷當前使用者屬性是否符合當前資源位投放的使用者屬性要求
public class UserGroupRule extends BasicRule<UserPortrait, UserPortraitRuleContext> {
    @Override
    public boolean evaluate(UserPortraitRuleContext context) {}
  
    @Override
    public void execute(UserPortraitRuleContext context) {
        UserPortrait userPortraitPO = context.getData();
        if(userPortraitPO.getUserGroup() == context.getBasicInfo().getUserGroup().code) {
          context.setValid(true);
        } else {
          context.setValid(false);
        }
    }
}
  
//規則3：判斷當前使用者是否在投放城市，具體邏輯省略
public class CityInfoRule extends BasicRule<UserPortrait, UserPortraitRuleContext> {}
//規則4：根據使用者的活躍度進行資源過濾，具體邏輯省略
public class UserPortraitRule extends BasicRule<UserPortrait, UserPortraitRuleContext> {} 
​
//我們通過spring將這些規則串起來組成一個一個請求鏈
    <bean name="serviceAvailableRule" class="com.dianping.takeaway.ServiceAvailableRule"/>
    <bean name="userGroupValidRule" class="com.dianping.takeaway.UserGroupRule"/>
    <bean name="cityInfoValidRule" class="com.dianping.takeaway.CityInfoRule"/>
    <bean name="userPortraitRule" class="com.dianping.takeaway.UserPortraitRule"/>
      
    <util:list id="userPortraitRuleChain" value-type="com.dianping.takeaway.Rule">
        <ref bean="serviceAvailableRule"/>
        <ref bean="userGroupValidRule"/>
        <ref bean="cityInfoValidRule"/>
        <ref bean="userPortraitRule"/>
    </util:list>
      
//規則執行
public class DefaultRuleEngine{
    @Autowired
    List<BasicRule> userPortraitRuleChain;
​
    public void invokeAll(RuleContext ruleContext) {
        for(Rule rule : userPortraitRuleChain) {
            rule.evaluate(ruleContext)
        }
    }
}
複製程式碼

責任鏈模式最重要的優點就是解耦，將客戶端與處理者分開，客戶端不需要了解是哪個處理者對事件進行處理，處理者也不需要知道處理的整個流程。在我們的系統中，後臺的過濾規則會經常變動，規則和規則之間可能也會存在傳遞關係，通過責任鏈模式，我們將規則與規則分開，將規則與規則之間的傳遞關係通過Spring注入到List中，形成一個鏈的關係。當增加一個規則時，只需要實現BasicRule介面，然後將新增的規則按照順序加入Spring中即可。當刪除時，只需刪除相關規則即可，不需要考慮程式碼的其他邏輯。從而顯著地提高了程式碼的靈活性，提高了程式碼的開發效率，同時也保證了系統的穩定性。

四、總結

本文從營銷業務出發，介紹了領域模型到程式碼工程之間的轉化，從DDD引出了設計模式，詳細介紹了工廠方法模式、策略模式、責任鏈模式以及狀態模式這四種模式在營銷業務中的具體實現。除了這四種模式以外，我們的程式碼工程中還大量使用了代理模式、單例模式、介面卡模式等等，例如在我們對DDD防腐層的實現就使用了介面卡模式，通過介面卡模式遮蔽了業務邏輯與第三方服務的互動。因篇幅原因不再進行過多的闡述。

對於營銷業務來說，業務策略多變導致需求多變是我們面臨的主要問題。如何應對複雜多變的需求，是我們提煉領域模型和實現程式碼模型時必須要考慮的內容。DDD以及設計模式提供了一套相對完整的方法論幫助我們完成了領域建模及工程實現。其實，設計模式就像一面鏡子，將領域模型對映到程式碼模型中，切實地提高程式碼的複用性、可擴充套件性，也提高了系統的可維護性。

當然，設計模式只是軟體開發領域內多年來的經驗總結，任何一個或簡單或複雜的設計模式都會遵循上述的七大設計原則，只要大家真正理解了七大設計原則，設計模式對我們來說應該就不再是一件難事。但是，使用設計模式也不是要求我們循規蹈矩，只要我們的程式碼模型設計遵循了上述的七大原則，我們會發現原來我們的設計中就已經使用了某種設計模式。

五、參考資料

• 軟體設計模式-百度百科
• 快速理解-設計模式六大原則
• Software design pattern
• 《設計模式之禪》，秦小波，機械工業出版社
• 《領域驅動設計-軟體核心複雜性應對之道》，Eric Evans，人民郵電出版社。
• 領域驅動設計在網際網路業務開發中的實踐

六、作者簡介

吳亮亮，2017年加入美團外賣，美團外賣營銷後臺團隊開發工程師。

招聘資訊

美團外賣上海研發中心長期招聘前端、資料倉儲、機器學習/資料探勘演算法工程師，歡迎感興趣的同學傳送簡歷到：tech@meituan.com（郵件標題註明：美團外賣-上海）