Why Process Engines Are Essential for Scalable Business Logic: A Deep Dive with MemberClub

As programmers, we should avoid over‑design and always choose the simplest solution that works; otherwise code becomes tangled and hard to maintain.

Initially I dismissed workflow orchestration as unnecessary over‑design, believing that direct method calls were more reliable. However, working in a middle‑platform team revealed that handling dozens of slightly different business lines quickly leads to massive if‑else blocks, making the codebase fragile and testing impractical.

if (biz == BizA || biz == BizB) {
    // common logic
    if (biz == BizA) {
        // BizA‑specific handling
    }
    if (biz == BizB) {
        // BizB‑specific handling
    }
}

When ten or more business lines are integrated, each new line adds more branches, increasing the risk of accidental regressions and online failures.

To solve the twin problems of code isolation and business extensibility, two techniques are proposed:

Use a workflow engine to configure separate execution chains for each business scenario.

Employ a plugin‑extension engine so that each business can implement its own variations without touching the core logic.

The open‑source MemberClub project (hosted on Gitee) illustrates both techniques. It provides a paid‑membership transaction solution and serves as a learning reference for building a business‑middle platform.

Configuring the Execution Chain

Different membership products require distinct purchase flows. The class DemoMemberPurchaseExtension defines three configurable flow chains, as shown in the screenshot below.

Defining Flow Nodes

Each node implements four methods: process, success, rollback, and callback. These methods encapsulate the core business step, the post‑success action, error recovery, and final cleanup respectively.

Executing the Flow

To run a flow, provide a context object and call FlowChain.execute. The engine links nodes in a chain and invokes them sequentially, following a responsibility‑chain pattern.

During execution, each node’s process method runs. If an exception occurs, the engine triggers rollback on the already‑executed nodes in reverse order. If all process calls succeed, the engine then calls success on each node in reverse order, followed by callback for final cleanup.

Flow Engine Execution Logic

The core of FlowChain.execute is shown below. It iterates over the node list, captures any exception, and then decides whether to roll back or to invoke success callbacks based on the presence of an exception.

public <T> void execute(FlowChain<T> chain, T context) {
    Exception exception = null;
    int index = -1;
    for (FlowNode<T> node : chain.getNodes()) {
        try {
            node.process(context);
            index++;
        } catch (Exception e) {
            if (e instanceof SkipException) {
                CommonLog.warn("Current flow:{} sent Skip request, stop further execution", node.getClass().getSimpleName());
                break;
            }
            exception = e;
            break;
        }
    }
    if (exception != null) {
        for (int i = index; i >= 0; i--) {
            FlowNode<T> node = chain.getNodes().get(i);
            try {
                node.rollback(context, exception);
            } catch (Exception e) {
                CommonLog.error("rollback execution exception, ignore name:{}", node.getClass().getSimpleName(), e);
            }
        }
    } else {
        for (int i = index; i >= 0; i--) {
            FlowNode<T> node = chain.getNodes().get(i);
            try {
                node.success(context);
            } catch (Exception e) {
                CommonLog.error("success execution exception, ignore name:{}", node.getClass().getSimpleName(), e);
            }
        }
    }
    for (int i = index; i >= 0; i--) {
        FlowNode<T> node = chain.getNodes().get(i);
        try {
            node.callback(context, exception);
        } catch (Exception e) {
            CommonLog.error("callback execution exception, ignore name:{}", node.getClass().getSimpleName(), e);
        }
    }
    if (exception != null) {
        throw exception;
    }
}

The full source code resides in the MemberClub repository (Gitee and GitHub links provided), making it easy for readers to explore the implementation in a real project.

Beyond the flow engine, MemberClub also integrates MyBatis‑Plus, ShardingSphere, Redis/Redisson, Apollo, Spring Cloud, RabbitMQ, H2, Swagger, Lombok, MapStruct, and several custom components such as a distributed retry mechanism, generic logging, inventory management, distributed locks, and Redis Lua scripts, offering a comprehensive reference for building robust middle‑platform systems.