在《[vivo 營銷自動化技術解密 |開篇](https://my.oschina.net/vivotech/blog/5259907)》中，我們從整體上介紹了vivo營銷自動化平臺的業務架構、核心業務模組功能、系統架構和幾大核心技術設計。

本次帶來的是系列文章的第2篇，本文詳細解析設計模式和相關應用如何幫助營銷自動化業務提升系統擴充套件性，以及實踐過程中的思考和總結。

# 一、引言

營銷業務本身極具複雜多變性，特別是伴隨著數字化營銷蓬勃發展的趨勢，在市場的不同時期、公司發展的不同階段、面向不同的使用者群體以及持續效果波動迭代，都會產生不同的營銷策略決策。

當面對隨時變化的業務場景時，系統的擴充套件性就顯得非常重要。而在談到系統設計擴充套件性的時候，總是首先會想到設計原則和設計模式。但設計模式不是銀彈，並不能解決所有問題，它只是前人提煉總結出來的招式方法，需要開發者根據實際業務場景進行合理的選擇、合適的變通，才能真正去解決實際場景中的問題，並總結形成自己的方法論。

那麼接下來我們看看設計模式是如何幫助我們在營銷策略引擎中提升系統擴充套件性的。

# 二、營銷策略引擎

![](https://static001.geekbang.org/infoq/70/7033432cdd53464aa95bdf49088b77f4.png)

先簡單介紹一下營銷策略引擎：策略引擎是透過搭建視覺化流程元件，定義各個流程節點，自動化執行活動業務流程，從而提供不同運營活動能力。其中核心活動業務流程主要包括三大部分：**運營活動配置**->**運營活動審批**->**運營活動執行**。

![](https://static001.geekbang.org/infoq/4a/4a8f7940c55ad23d7d709371142e8293.png)

-   運營活動配置：運營人員在系統後臺配置運營活動。包括活動名稱、活動時間、觸發條件、活動使用者和具體推送渠道（如簡訊、微信、push推送等）。
    
-   運營活動審批：品質/主管人員審批運營活動配置。審批流程涉及了活動審批節點和人員的配置，審批相關的回撥操作配置。
    
-   運營活動執行：系統自動化執行運營活動的過程。即具體的渠道如簡訊、微信、push等推送活動的任務執行下發流程，包括使用者資料準備，資料下發推送和資料效果回收等。

# 三、設計模式具體應用

## 3.1 運營活動配置

### 3.1.1 工廠模式

具體場景

一般情況下，根據不同的使用者和活動場景，運營藉助資料分析會決策出不同的活動策略，比如需要建立簡訊推送策略、微信圖文推送策略、App Push推送策略等。此時我們可以使用工廠模式，統一管理具體推送策略的建立。

![](https://static001.geekbang.org/infoq/4f/4f296e57ea2e0ab1a4d7a83f5e44ca4d.png)

模式分析

在GoF《設計模式：可複用物件導向軟體的基礎》中：工廠模式被分成了工廠方法和抽象工廠兩類，而簡單工廠模式（又稱靜態工廠模式）被看作是工廠方法的一種特例。不過由於簡單工廠和工廠方法相對更簡單和易於理解，程式碼可讀性也更強，因此在實際專案中更加常用。

其中簡單工廠的適用場景：

-   a.工廠類負責建立的物件比較少，工廠方法中的建立邏輯簡單。
    
-   b.客戶端無須關心建立具體物件的細節，僅需知道傳入工廠類的型別引數。

而工廠方法的適用場景：

-   a.工廠類物件建立邏輯相對複雜，需要將工廠例項化延遲到其具體工廠子類中。
    
-   b.適合需求變更頻繁的場景，可以利用不同的工廠實現類支援新的工廠建立方案，更符合開閉原則，擴充套件性更好。

典型程式碼示例

```java
//抽象產品類
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;
    }
}
```

實際程式碼

```java
/**
 * @author chenwangrong
 * 活動策略工廠類
 */
@Component
@Slf4j
public class ActivityStrategyFactory {
 
    /**
     * 獲得渠道型別對應的策略
     *
     * @param channelType channelType
     * @return OperationServiceStrategy
     */
    public static ActivityStrategy getActivityStrategy(ChannelTypeEnum channelType) {
 
        ChannelTypeStrategyEnum channelTypeStrategyEnum = ChannelTypeStrategyEnum.getByChannelType(channelType);
        Assert.notNull(channelTypeStrategyEnum , "指定的渠道型別[channelType=" + channelType + "]不存在");
 
        String strategyName= channelTypeStrategyEnum.getHandlerName();
        Assert.notNull(strategyName, "指定的渠道型別[channelType=" + channelType + "未配置策略");
 
        return (ActivityStrategy)SpringContextHolder.getBean(handlerName);
    }
 
 
    public enum ChannelTypeStrategyEnum {
        /**
         * 簡訊渠道
         */
        SMS(ChannelTypeEnum.SMS, "smsActivityStrategy"),
        /**
         * 微信渠道
         */
        WX_NEWS(ChannelTypeEnum.WX, "wxActivityStrategy"),
        /**
         * push渠道
         */
        PUSH(ChannelTypeEnum.PUSH, "pushActivityStrategy"),;
 
        private final ChannelTypeEnum channelTypeEnum;
 
        private final String strategyName;
 
        ChannelTypeStrategyEnum (ChannelTypeEnum channelTypeEnum, String strategyName) {
            this.channelTypeEnum = channelTypeEnum;
            this.strategyName= strategyName;
        }
 
 
        public String getStrategyName() {
            return strategyName;
        }
 
        public static ChannelTypeStrategyEnum getByChannelType(ChannelTypeEnum channelTypeEnum) {
            for (ChannelTypeStrategyEnum channelTypeStrategyEnum : values()) {
                if (channelTypeEnum == channelTypeStrategyEnum.channelTypeEnum) {
                    return channelTypeStrategyEnum ;
                }
            }
            return null;
        }
    }
}
```

**實踐總結**

在實際專案程式碼中我們採用的是**簡單工廠模式**（靜態工廠模式），實現時利用列舉（或者對映配置表）來儲存渠道型別與具體策略實現類的對映關係，再結合Spring的單例模式，來進行策略類的建立。

相比於工廠方法模式，在滿足業務的前提下，減少了工廠類數量，程式碼更加簡單適用。

### 3.1.2 模板方法模式

**具體場景**

在建立不同型別運營活動策略的時候，可以發現除了儲存具體活動渠道配置資訊不一樣之外，建立過程中很多操作流程是相同的：比如**儲存活動基本配置資訊，審計日誌上報，建立活動審批工單，建立完成後訊息提醒等**。

原有實踐

```java
/**
 * 簡訊活動類
 *
 */
@Service
public class SmsActivityStrategy{
  
    /**
     * 執行渠道傳送
     *
     * @param msgParam msgParam
     */
    public ProcessResult createActivity(ActParam param) {
         //儲存活動基礎資訊
         saveActBaseConfig(param);
         //儲存簡訊活動配置
         createSmsActivity(param);
         //審計日誌上報 ...
         //建立活動審批工單 ...
         //訊息通知 ...
         sendNotification(param);
    }
}
 
/**
 * Push活動類
 *
 */
@Service
public class PushActivityStrategy{
  
    /**
     * 執行渠道傳送
     *
     * @param msgParam msgParam
     */
    public ProcessResult createActivity(ActParam param) {
         //儲存活動基礎資訊
         saveActBaseConfig(param);
         //儲存Push活動配置
         createChannelActivity(param);
         //審計日誌上報 ...
         //建立活動審批工單 ...
         //訊息通知 ...
         sendNotification(param);
    }
}
 
...
```

![](https://static001.geekbang.org/infoq/2a/2a9a659eec97fa34fc8f8caff0e89601.png)

對於每種活動策略而言，這些操作都是必需的且操作流程都是固定的，所以可以將這些操作提取成公用的流程，此時就考慮到了模板方法模式。

**模式分析**

在GoF《設計模式：可複用物件導向軟體的基礎》：模板方法模式是在一個方法中定義一個演算法骨架，並將某些步驟推遲到其子類中實現。模板方法模式允許子類在不改變演算法結構的情況下重新定義演算法的某些步驟。

上面所指的“演算法”，可以理解為業務邏輯，而‘’演算法骨架“即是模板，包含‘’演算法骨架“的方法就是模板方法，這也是模板方法模式名稱的來源。

模板方法模式適用場景：業務邏輯由確定的步驟組成，這些步驟的順序要是固定不變的，不同的具體業務之間某些方法或者實現可以有所不同。

實現時一般透過抽象類來定義一個邏輯模板和框架，然後將無法確定的部分抽象成抽象方法交由子類來實現，呼叫邏輯仍在抽象類中完成。

典型程式碼示例

```java
//模板類
public abstract class AbstractTemplate {
 
//業務邏輯1
protected abstract void doStep1();
//業務邏輯2
protected abstract void doStep2();
 
//模板方法
public void templateMethod(){
     this.doStep1();
     //公共邏輯
       ......
     this.doStep2();
   }
}
 
//具體實現類1
public class ConcreteClass1  extends AbstractTemplate {
  //實現業務邏輯1
  protected void doStep1()
  {
     //業務邏輯處理
  }
 
  //實現業務邏輯2
  protected void doStep2()
  {
    //業務邏輯處理
   }
}
 
//具體實現類2
public class ConcreteClass2  extends AbstractTemplate {
  //實現業務邏輯1
  protected void doStep1()
  {
     //業務邏輯處理
  }
 
  //實現業務邏輯2
  protected void doStep2()
  {
    //業務邏輯處理
   }
}
 
// 呼叫類
public class Client {
 public static void main(String[] args)
  {
    AbstractTemplate class1=new ConcreteClass1();
    AbstractTemplate class2=new ConcreteClass2();
   //呼叫模板方法
    class1.templateMethod();
    class2.templateMethod();
   }
}
```

實際程式碼

```java
/**
 * 活動建立模板類
 *
 * @author chenwangrong
 */
@Slf4j
public abstract class AbstractActivityTemplate{
 
    /**
     * 儲存具體活動配置
     *
     * @param param 活動引數
     * @return ProcessResult 處理結果
     */
    protected abstract ProcessResult createChannelActivity(ActParam param);
 
    /**
     * 執行活動建立
     *
     * @param msgParam msgParam
     */
    public ProcessResult createActivity(ActParam param) {
         //儲存活動基礎資訊
         saveActBaseConfig(param);
         //儲存具體渠道配置
         createChannelActivity(param);
         //審計日誌上報 ...
         //訊息通知 ...
    }
}
 
/**
 * 簡訊活動類
 *
 */
@Service
public class SmsActivityStrategy extends AbstractActivityTemplate{
  
    /**
     * 建立簡訊渠道活動配置
     *
     * @param msgParam msgParam
     */
    public ProcessResult createChannelActivity(ActParam param) {
         //僅需要實現：儲存簡訊活動配置
         createSmsActivity(param);    
    }
}
 
（其他渠道活動類似，此處省略）
 
 
// 呼叫類
public class Client {
 public static void main(String[] args)
  {
    AbstractActivityTemplate smsActivityStrategy=new SmsActivityStrategy();
    AbstractActivityTemplate pushActivityStrategy=new PushActivityStrategy();
 
    ActParam param = new ActParam();
 
   //呼叫具體活動實現類
    smsActivityStrategy.createActivity(param);
    pushActivityStrategy.createActivity(param);
   }
}
```

實踐總結

模板方法模式有兩大作用：**複用和擴充套件**。複用是指所有的子類可以複用父類中提供的模板方法的程式碼。擴充套件是指框架透過模板模式提供功能擴充套件點，讓使用者可以在不修改框架原始碼的情況下，基於擴充套件點定製化框架的功能。

模板方法非常適用於有通用業務邏輯處理流程，同時又在具體流程上存在一定差異的場景，可以透過將流程骨架抽取到模板類中，將可變的差異點設定為抽象方法，達到封裝不變部分，擴充套件可變部分的目的。

### 3.1.3 策略模式

**具體場景**

上述我們透過模板方法模式抽取出了公共流程骨架，但這裡還存在一個問題：**呼叫類仍需要明確知道具體實現類是哪個，例項化後才可進行呼叫**。也就是每一次增加新的渠道活動時，呼叫方都必須修改呼叫邏輯，新增新的活動實現類的初始化呼叫，顯然不利用業務的擴充套件性。

在建立運營活動過程中，不同型別的活動會對應著不同的建立流程，呼叫方只需要根據渠道型別來進行區分，而無需理會其中具體的業務邏輯。此時策略模式是一個比較好的選擇。

![](https://static001.geekbang.org/infoq/ec/eccbf4974b67691d1ec6bd78455338c2.png)

**模式分析**

在GoF《設計模式：可複用物件導向軟體的基礎》中：策略模式定義一族演算法類，將每個演算法分別封裝起來，讓它們可以互相替換。策略模式可以使演算法的變化獨立於使用它們的呼叫方。

典型程式碼示例

```java
//策略介面定義
public interface Strategy {
    void doStrategy();
}

//策略具體實現類（多個）
public class StrategyA implements Strategy{
    @Override
    public void doStrategy() {
    }
}

//上下文操作類， 遮蔽高層模組對策略的直接訪問
public class Context {
    private Strategy strategy = null;

public Context(Strategy strategy) {
        this.strategy = strategy;
    }
 
    public void doStrategy() {
        strategy.doStrategy();
    }
}
```

實際程式碼

```java
/**
 * 渠道活動建立策略介面
 *
 */
public interface ActivityStrategy {
 
    /**
     * 建立渠道活動配置
     *
     * @param param 活動引數
     * @return 
     */
    void createActivity(ActParam param);
}
 
/**
 * 活動模板類
 *
 */
@Slf4j
public abstract class AbstractActivityTemplate implements ActivityStrategy {
 
    /**
     * 抽象方法：具體渠道活動建立
     *
     */
    protected abstract ProcessResult createChannelActivity(ActParam param);
 
    @Override
    public ProcessResult createActivity(ActParam param) {
         //儲存活動基礎資訊
         saveActBaseConfig(param);
         //儲存具體渠道配置
         createChannelActivity(param);
         //審計日誌上報 ...
         //訊息通知 ...
    }
}
 
/**
 * 簡訊推送策略具體實現類
 *
 */
@Component
public class SmsChannelActivityStrategy extends AbstractActivityTemplate {
    @Override
    public void createChannelActivity(ActParam param) {
        //儲存簡訊配置資料
    }
}
（其他渠道活動類似，此處省略）
 
 
/**
 * 策略呼叫入口
 *
 */
@Slf4j
@Component
public class ActivityContext {
 
   @Resource
   private ActivityStrategyFactory activityStrategyFactory ;
 
      public void create(ActParam param) {
            //透過前面的工廠模式的程式碼，獲取具體渠道對應的策略類
            ActivityStrategy strategy = activityStrategyFactory.getActivityStrategy(param.ChannelType);
            //執行策略
            strategy.createActivity(param);
      }
}
```

實際編碼過程中，我們加入了ChannelActivityStrategy作為渠道活動建立策略介面，並用模板類AbstractActivityTemplate實現該介面，同時結合工廠模式建立具體策略，**至此將三種模式結合了起來**。

**實踐總結**

策略模式在專案開發過程中經常用於消除複雜的if else複雜邏輯，後續如果有新的渠道活動時，只需要新增對應渠道的活動建立邏輯即可，可以十分便捷地對系統業務進行擴充套件。

在專案實踐過程，經常會將工廠模式、模板方法模式和策略模式一起結合使用。**模板方法模式進行業務流程公共骨架的抽取，策略模式進行具體子流程策略的實現和呼叫的封裝，而工廠模式可以進行子流程策略的建立。**

多種模式的結合使用可以充分發揮出各個模式的優勢，達到真正提升系統設計擴充套件性的目的。

## 3.2 運營活動執行

### 3.2.1 狀態模式

**具體場景**

在運營活動的執行過程中，會涉及活動狀態的變更，以及變更前的條件檢測和變更後的操作處理。與之相對應地，我們很容易就會想到狀態模式。

![](https://static001.geekbang.org/infoq/5d/5d9b20994bf73d283fb0b49fda6c439f.png)

**模式分析**

在 GoF 經典的《設計模式：可複用物件導向軟體的基礎》中：狀態模式允許一個物件在其內部狀態改變的時候改變其行為。

狀態模式的作用就是分離狀態的行為，透過維護狀態的變化，來呼叫不同狀態對應的不同功能。它們的關係可以描述為：**狀態決定行為**。由於狀態是在執行期被改變的，因此行為也會在執行期隨著狀態的改變而改變。

典型程式碼示例

```java
/**
 * 狀態模式
 * 抽象狀態類
 * */
interface State {
    //狀態對應的處理
    void handle()
}
 
  
//具體狀態關現類
public  class ConcreteStateA implements  State {
    @Override
    public void handle() {
    }
}
 
public  class ConcreteStateB implements  State {
    @Override
    public void handle() {
    }
}
 
//環境類Context，訪問入口
public class Context {
    //持有一個State型別的物件例項
    private State state;
 
    public void setState(State state) {
        this.state = state;
    }
      
    public void request() {
        //轉調state來處理
        state.handle();
    }
}
 
public class Client {
    public static void main(String[] args){
        //建立狀態
        State state = new ConcreteStateB();
        //建立環境
        Context context = new Context();
        //將狀態設定到環境中
        context.setState(state);
        //請求
        context.request();
    }
}
```

實踐總結

在實際軟體專案開發中，業務狀態不多且狀態轉移簡單的場景， 可使用狀態模式來實現；但如果是涉及的業務流程狀態轉移繁雜時，使用狀態模式會引入非常多的狀態類和方法，當狀態邏輯有變更時，程式碼也會變得難以維護，此時使用狀態模式並不十分適合。

而當流程狀態繁多，事件校驗和觸發執行動作包含的業務邏輯比較複雜時，如何去實現呢？

這裡我們必須停下來思考：使用設計模式只是解決實際問題的一種手段，但設計模式不是一把“萬能的”錘子，需要清楚地瞭解到它的優勢和不足。而這種問題場景下，業界已經有一個更通用的方案——有限狀態機，透過更高層的封裝，提供給業務更便捷的應用。

### 3.2.2 狀態模式的應用——有限狀態機

有限狀態機（Finite-State Machine , 縮寫：**FSM**），業界簡稱狀態機。它亦是由**事件**、**狀態**、**動作** 三大部分組成，三者的關係是：事件觸發狀態的轉移，狀態的轉移觸發後續動作的執行。狀態機可以基於傳統的狀態模式硬編碼來實現，也可以透過**資料庫/檔案配置**或者**DSL的方式**來儲存狀態及轉移配置來實現（推薦）。

![](https://static001.geekbang.org/infoq/99/994c7abfbbb01c98d94c6881854c9d7d.png)

業界中也已湧現出了不少開源狀態機的框架，比較常用的有Spring-statemachine（Spring官方提供） 、squirrel statemachine和阿里開源的cola-statemachine。

**實際應用**

在實際專案開發中，我們針對自身業務的特點：**業務流程狀態多，但是事件觸發和狀態變更動作相對簡單**，故而選擇了無狀態、更加輕量級的解決方案——基於開源的狀態機實現思想進行開發。（關於狀態機的實現和使用選型會在後續的文章中做進一步的分析，感興趣的童鞋可以訪問官網先做了解）。

實踐程式碼

```java
/**
 * 狀態機工廠類
 */
public class StatusMachineEngine {
    private StatusMachineEngine() {
    }
    private static final Map<ordertypeenum string=""> STATUS_MACHINE_MAP = new HashMap();
 
    static {
        //簡訊推送狀態
        STATUS_MACHINE_MAP.put(ChannelTypeEnum.SMS, "smsStateMachine");
        //PUSH推送狀態
        STATUS_MACHINE_MAP.put(ChannelTypeEnum.PUSH, "pushStateMachine");
        //......
    }
 
    public static String getMachineEngine(ChannelTypeEnum channelTypeEnum) {
        return STATUS_MACHINE_MAP.get(channelTypeEnum);
    }
 
   /**
     * 觸發狀態轉移
     * @param channelTypeEnum
     * @param status 當前狀態
     * @param eventType 觸發事件
     * @param context 上下文引數
     */
    public static void fire(ChannelTypeEnum channelTypeEnum, String status, EventType eventType, Context context) {
        StateMachine orderStateMachine = StateMachineFactory.get(STATUS_MACHINE_MAP.get(channelTypeEnum));
        //推動狀態機進行流轉，具體介紹本期先省略
        orderStateMachine.fireEvent(status, eventType, context);
    }
 
/**
 * 簡訊推送活動狀態機初始化
 */
@Component
public class SmsStateMachine implements ApplicationListener<contextrefreshedevent> {
 
    @Autowired
    private  StatusAction smsStatusAction;
    @Autowired
    private  StatusCondition smsStatusCondition;
 
    //基於DSL構建狀態配置，觸發事件轉移和後續的動作
    @Override
    public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {
        StateMachineBuilder<string eventtype="" context=""> builder = StateMachineBuilderFactory.create();
        builder.externalTransition()
                .from(INIT)
                .to(NOT_START)
                .on(EventType.TIME_BEGIN)
                .when(smsStatusAction.checkNotifyCondition())
                .perform(smsStatusAction.doNotifyAction());
        builder.externalTransition()
                .from(NOT_START)
                .to(DATA_PREPARING)
                .on(EventType.CAL_DATA)
                .when(smsStatusCondition.doNotifyAction())
                .perform(smsStatusAction.doNotifyAction());
        builder.externalTransition()
                .from(DATA_PREPARING)
                .to(DATA_PREPARED)
                .on(EventType.PREPARED_DATA)
                .when(smsStatusCondition.doNotifyAction())
                .perform(smsStatusAction.doNotifyAction());
        ...(省略其他狀態)
        builder.build(StatusMachineEngine.getMachineEngine(ChannelTypeEnum.SMS));
    }
 
   //呼叫端
   public class Client {
     public static void main(String[] args){
          //構建活動上下文
          Context context = new Context(...);
         // 觸發狀態流轉
          StatusMachineEngine.fire(ChannelTypeEnum.SMS, INIT, EventType.SUBMIT, context);
      }
   }
}
```

透過預定義狀態轉換流程的方式，實現ApplicationListener介面，在應用啟動時將事件、狀態轉移條件和觸發操作的流程載入到狀態機工作記憶體中，由事件觸發驅動狀態機進行自動流轉。

**實踐總結**

實際場景中，不必強行套用設計模式，而是應當充分結合業務的特點，同時針對設計模式的優劣勢，進行更加合適的選型或者進一步擴充套件。

## 3.3 自動化運營活動審批

### 3.3.1 設計模式的綜合應用——工作流引擎

**具體場景**

為了做好品質和風險管控，活動建立需要加入審批環節，把控運營活動的釋出執行，同時對於不同型別的運營活動，可能涉及的業務領域和部門各不相同，審批管控人員也不一樣，需要配置相對應的審批關係。

此時需要做到：

-   a.審批流程全配置化，易修改和新增；
    
-   b.業務流程節點可自由編排，元件公用化；
    
-   c.流程資料持久化，審批過程資料需要進行操作監控。

針對這方面的需求，業界有一套通用的業務工具——**工作流引擎**。工作流引擎顯然並不屬於具體某一種設計模式的實現，它是涵蓋了多種設計模式的元件應用。

不僅僅是審批功能，其實前面**自動化營銷流程引擎設計**也同樣是使用工作流引擎**搭建流程元件**：

![](https://static001.geekbang.org/infoq/fb/fb48083afab952eeecabb9b70ab25003.png)

**狀態機 VS 工作流引擎**

工作流引擎和狀態機似乎存在非常多的相似之處，都可以透過定義流程的節點、轉移條件和相應觸發的操作來完成業務流程。**如果只從適用場景的複雜性上看，狀態機更適用於單維度的業務問題，能夠清晰地描繪出所有可能的狀態以及導致轉換的事件，更加靈活輕便；而工作流引擎則更適合業務流程管理，解決如大型CRM複雜度更高的流程自動化問題，可以改善整體業務流程的效率。**

在業界的工作流引擎中，比較著名的有Activiti和JBPM等。（關於狀態機和工作流引擎的對比、開源工作流引擎的具體介紹和選型，以及如何自行開發構建一款基本的工作流引擎元件，同樣是會在後續的文章中做進一步分析，本文由於主題和篇幅的原因暫不做詳細介紹。）

在實際開發過程中，我們是基於開源的Activiti工作流引擎自研了一套簡易版的工作流引擎，精簡了許多相關的配置，只留下了核心流程操作和資料記錄。

工作流引擎流程圖：

![](https://static001.geekbang.org/infoq/50/50d6d90bc4f0e256f5679dff2ae5c6a4.png)

**實踐總結**

工作流引擎是涵蓋了多種設計模式的應用元件，只有在複雜多變的業務場景中才需要應用，需要結合業務進行仔細評估。在**合適的場景使用合適的解決方案，遵循系統架構設計的簡單、合適、可演化原則，不過度設計。**

# 四、總結

本文基於自動化營銷的業務實踐，分析介紹了工廠方法模式、模板方法模式、策略模式以及狀態模式這四種模式在專案開發中的具體實現過程。也在單純的模式之外介紹了狀態機和工作流引擎這些涵蓋了多種設計模式系統元件，並分享了過程中的選擇和思考。

面對業務複雜多變的需求，需要時刻關注系統設計的複用性和可擴充套件性，而設計原則和設計模式可以在系統設計實現時給予我們方向性的指導，同時更需要根據實際業務場景進行合理的選擇，合適的變通，不斷完善自己的方法論。

後續我們將帶來系列專題文章的其他內容，每一篇文章都會對裡面的技術實踐進行詳盡解析，敬請期待。

> 作者：vivo網際網路伺服器團隊-Chen Wangrong</string></contextrefreshedevent></ordertypeenum></t></t>

設計模式如何提升 vivo 營銷自動化業務擴充套件性 | 引擎篇01

相關文章