Applying Design Patterns to Improve Extensibility in Vivo Marketing Automation Engine

The article, authored by the Vivo Internet Server Team, presents a detailed analysis of how classic design patterns can be leveraged to enhance the scalability and maintainability of a marketing automation platform.

1. Introduction – Marketing automation systems face rapidly changing business scenarios, making extensibility a critical concern. The author emphasizes that design patterns are not silver bullets but useful tools when applied appropriately.

2. Marketing Strategy Engine – The engine is built as a visual workflow composed of three core stages: Operation Activity Configuration → Operation Activity Approval → Operation Activity Execution . Diagrams illustrate the flow and the role of each stage.

3. Design Pattern Applications

3.1 Factory Pattern – Used to create different channel‑specific strategies (SMS, WeChat, Push) through a static factory. The pattern separates object creation from usage, allowing easy addition of new channels.

// Abstract product
public abstract class Product {
    public abstract void method();
}
// Concrete product
class ProductA extends Product {
    @Override
    public void method() { /* specific logic */ }
}
// Abstract factory
abstract class Factory
{
    abstract Product createProduct(Class
c);
}
// Concrete factory
class FactoryA extends Factory {
    @Override
    Product createProduct(Class c) {
        return (Product) Class.forName(c.getName()).newInstance();
    }
}
// Real factory used in the project
@Component
public class ActivityStrategyFactory {
    public static ActivityStrategy getActivityStrategy(ChannelTypeEnum channelType) { /* ... */ }
}

3.2 Template Method Pattern – Extracts the common workflow of activity creation (saving base config, audit logging, notification) into an abstract template, while allowing subclasses to implement channel‑specific steps.

public abstract class AbstractTemplate {
    protected abstract void doStep1();
    protected abstract void doStep2();
    public void templateMethod() {
        doStep1();
        // common logic
        doStep2();
    }
}
public class ConcreteClass1 extends AbstractTemplate {
    protected void doStep1() { /* SMS specific */ }
    protected void doStep2() { /* SMS specific */ }
}

3.3 Strategy Pattern – Decouples the client from concrete channel implementations. The client selects a strategy based on channel type, enabling easy addition of new strategies without modifying client code.

public interface Strategy { void doStrategy(); }
public class StrategyA implements Strategy { @Override public void doStrategy() { /* ... */ } }
public class Context {
    private Strategy strategy;
    public Context(Strategy strategy) { this.strategy = strategy; }
    public void execute() { strategy.doStrategy(); }
}

3.4 State Pattern – Models the lifecycle of an activity (INIT → NOT_START → DATA_PREPARING → …). The article notes that for complex workflows a finite‑state machine (FSM) is often more suitable.

interface State { void handle(); }
class ConcreteStateA implements State { @Override public void handle() { /* ... */ } }
class Context {
    private State state;
    public void setState(State s) { this.state = s; }
    public void request() { state.handle(); }
}

4. Finite State Machine (FSM) – Describes how FSMs combine events, states, and actions, and mentions popular Java implementations such as Spring‑Statemachine, Squirrel‑Statemachine, and Alibaba’s Cola‑Statemachine. Sample code shows a factory that maps channel types to specific state‑machine beans and triggers transitions.

public class StatusMachineEngine {
    private static final Map
STATUS_MACHINE_MAP = new HashMap<>();
    static { STATUS_MACHINE_MAP.put(ChannelTypeEnum.SMS, "smsStateMachine"); }
    public static void fire(ChannelTypeEnum channel, String status, EventType event, Context ctx) {
        StateMachine sm = StateMachineFactory.get(STATUS_MACHINE_MAP.get(channel));
        sm.fireEvent(status, event, ctx);
    }
}

5. Workflow Engine – For more complex, multi‑dimensional processes, a workflow engine (e.g., Activiti, JBPM) is introduced. The article explains that a workflow engine aggregates multiple design patterns and is appropriate when business processes become highly configurable.

6. Conclusion – The author reiterates that while design patterns provide reusable solutions, they must be selected based on concrete business needs. Combining factory, template method, strategy, and state patterns, together with FSM or workflow engines, yields a flexible and extensible marketing automation system.