設計模式在外賣營銷業務中的實踐
摘要:本文從營銷業務出發,介紹了領域模型到代碼工程之間的轉化,從DDD引出了設計模式,詳細介紹了工廠方法模式、策略模式、責任鏈模式以及狀態模式這四種模式在營銷業務中的具體實現。//更新用戶信息以及結算 } //新用戶返獎具體策略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
一、前言
隨着美團外賣業務的不斷迭代與發展,外賣用戶數量也在高速地增長。在這個過程中,外賣營銷發揮了“中流砥柱”的作用,因爲用戶的快速增長離不開高效的營銷策略。而由於市場環境和業務環境的多變,營銷策略往往是複雜多變的,營銷技術團隊作爲營銷業務的支持部門,就需要快速高效地響應營銷策略變更帶來的需求變動。因此,設計並實現易於擴展和維護的營銷系統,是美團外賣營銷技術團隊不懈追求的目標和必修的基本功。
本文通過自頂向下的方式,來介紹設計模式如何幫助我們構建一套易擴展、易維護的營銷系統。本文會首先介紹設計模式與領域驅動設計(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 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 設計模式實踐
業務建模
對於投放業務,就是要在這些資源位中展示符合當前用戶的資源。其流程如下圖所示:
從流程中我們可以看到,首先運營人員會配置需要展示的資源,以及對資源進行過濾的規則。我們資源的過濾規則相對靈活多變,這裏體現爲三點:
- 過濾規則大部分可重用,但也會有擴展和變更。
- 不同資源位的過濾規則和過濾順序是不同的。
- 同一個資源位由於業務所處的不同階段,過濾規則可能不同。
過濾規則本身是一個個的值對象,我們通過領域服務的方式,操作這些規則值對象完成資源位的過濾邏輯。下圖介紹了資源位在進行用戶特徵相關規則過濾時的過程:
爲了實現過濾規則的解耦,對單個規則值對象的修改封閉,並對規則集合組成的過濾鏈條開放,我們在資源位過濾的領域服務中引入了責任鏈模式。
模式:責任鏈模式
模式定義:使多個對象都有機會處理請求,從而避免了請求的發送者和接受者之間的耦合關係。將這些對象連成一條鏈,並沿着這條鏈傳遞該請求,直到有對象處理它爲止。
責任鏈模式通用類圖如下:
我們通過一段比較通用的代碼來解釋如何使用責任鏈模式:
//定義一個抽象的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年加入美團外賣,美團外賣營銷後臺團隊開發工程師。