Decoupling Chain Business Logic: Challenges, Design Principles, and Implementation

This article analyzes the sources of complexity in chain (multi‑store) business scenarios, especially for offline‑store merchants that need a replicable operating model for rapid expansion.

It points out three typical pain points for developers:

System is hard to understand because original design and code are tangled.

Code changes affect many low‑level functions, making modifications risky.

Maintenance and deployment are inconvenient since a single change often requires redeploying core applications.

To illustrate the problem, the author presents a concrete example of the current product‑editing flow. The implementation consists of two steps: updating a product and sending a change message, then a consumer receives the message and updates store‑level products. The pseudo‑code is shown below.

updateItem(req) {
    // 前置校验：参数校验、权限校验、编码重复性校验等等
    validate(...);
    // 如果是总部更新
    if(updateByHeadQuarter(...)) {
        // 更新总部商品
        ...
    }
    // 如果是门店更新
    if(updateByStore(...)) {
        // 只允许更新部分属性  
        ...
    }
    // 发消息
    sendMsg(...);
}

The consumer handling the message is also shown:

handle(msg) {
    // 根据不同的商品事件类型，走不同的处理动作
    switch (msg.goodsEventType) {
        case NEW:
            ...
        case UPDATE:
            processUpdateEvent(msg);
        case TAKE_UP_DOWN:
            ...
        case XXX:
            ...
    }
}

processUpdateEvent(msg) {
    // 如果是总部更新，则同步信息到门店
    if (updateByHeadQuarter()) {
        // 查询总部下所有门店
        getAllStore(...);
        // 更新这些门店的商品信息
        updateAllStore(...);
    }
}

The author identifies three core problems in this implementation:

Coupling : General product logic and chain‑specific logic (e.g., which attributes a store can modify) are mixed, so changes to chain rules affect the generic code.

Busy consumer : A single consumer handles all product events, including the separate concern of synchronizing headquarters data to stores.

Lack of reuse : Similar operations (single‑product edit vs. batch edit) are implemented in duplicated code.

To address these issues, the article proposes an architectural refactor based on classic design principles:

Open‑Closed Principle (OCP) : Isolate store‑specific attribute rules from generic editing logic.

Single Responsibility Principle (SRP) : Extract the headquarters‑to‑store synchronization into its own consumer.

Domain‑driven separation : Distinguish between single‑store capabilities and chain capabilities .

By classifying each business scenario as either a single‑store ability or a chain ability, the system can be split into two services:

mei‑goods : Implements all single‑store product functions.

mei‑chain : Implements chain‑specific logic such as cross‑store permission checks and synchronization.

This decomposition brings three practical benefits:

Code decoupling : Adjusting chain rules only requires changes in mei‑chain , leaving mei‑goods untouched.

Deployment isolation : Failure of the chain service does not affect basic single‑store operations.

Clear responsibilities : Teams can focus on their domain (chain vs. single‑store) and avoid mixing concerns.

The article also discusses the role of an API layer as a thin aggregation point, the alignment with Serverless thinking (small, focused interfaces), and the relationship with Domain‑Driven Design (DDD). It concludes that this architectural approach not only improves system stability and developer productivity but also influences product thinking by encouraging clear domain boundaries.

Finally, the author reflects on the limits of the approach (e.g., some business scenarios exist only in chain contexts such as supply‑chain or finance) and provides references for further reading.