Mastering Complex Business Logic: A Structured Decomposition Methodology

1. Business Background

Retail 通 is an B2B platform that supplies offline stores. The goal is to digitize the traditional supply‑chain, improve efficiency, and support new‑retail initiatives, with Alibaba acting as the platform providing service functions within the Bsbc ecosystem.

2. Process Decomposition

Complex business logic should not be placed in a single service method. Instead, apply a divide‑and‑conquer strategy, breaking the workflow into phases and steps.

For the product‑on‑sale use case, the command OnSaleNormalItemCmdExe orchestrates three phases: initialization, data validation, and processing.

@Command
public class OnSaleNormalItemCmdExe {
    @Resource
    private OnSaleContextInitPhase onSaleContextInitPhase;
    @Resource
    private OnSaleDataCheckPhase onSaleDataCheckPhase;
    @Resource
    private OnSaleProcessPhase onSaleProcessPhase;

    @Override
    public Response execute(OnSaleNormalItemCmd cmd) {
        OnSaleContext onSaleContext = init(cmd);
        checkData(onSaleContext);
        process(onSaleContext);
        return Response.buildSuccess();
    }

    private OnSaleContext init(OnSaleNormalItemCmd cmd) {
        return onSaleContextInitPhase.init(cmd);
    }

    private void checkData(OnSaleContext onSaleContext) {
        onSaleDataCheckPhase.check(onSaleContext);
    }

    private void process(OnSaleContext onSaleContext) {
        onSaleProcessPhase.process(onSaleContext);
    }
}

The OnSaleProcessPhase further consists of multiple steps such as publishing the offer, binding inventory, syncing routes, and firing domain events.

@Phase
public class OnSaleProcessPhase {
    @Resource
    private PublishOfferStep publishOfferStep;
    @Resource
    private BackOfferBindStep backOfferBindStep;
    // ... other steps omitted

    public void process(OnSaleContext onSaleContext) {
        SupplierItem supplierItem = onSaleContext.getSupplierItem();
        generateOfferGroupNo(supplierItem);
        publishOffer(supplierItem);
        bindBackOfferStock(supplierItem);
        syncStockRoute(supplierItem);
        setVirtualProductExtension(supplierItem);
        markSendProtection(supplierItem);
        recordChangeDetail(supplierItem);
        syncSupplyPriceToBackOffer(supplierItem);
        setCombineProductExtension(supplierItem);
        removeSellOutTag(offerId);
        fireDomainEvent(supplierItem);
        closeIssues(supplierItem);
    }
}

The author argues that a lightweight composed‑method pattern is sufficient; heavy workflow engines add unnecessary complexity and should be avoided unless strong visual orchestration is required.

3. Problems After Decomposition

Two issues arise:

Fragmented domain knowledge: Each use‑case only knows its own steps, leading to duplicated logic and loss of a unified model.

Weak business expression: Code becomes a series of data‑fetch‑compute‑store steps without clear domain concepts.

Example: inventory validation for combined products originally involved many if‑else branches. After introducing a domain model, the logic simplifies dramatically.

if (backOffer.isCloudWarehouse()) {
    return;
}
if (backOffer.isNonInWarehouse()) {
    throw new BizException("亲，不能发布Offer，请联系仓配运营人员，建立品仓关系！");
}
if (backOffer.getStockAmount() < 1) {
    throw new BizException("亲，实仓库存必须大于0才能发布，请确认已补货.\r[id:" + backOffer.getSupplierItem().getCspuCode() + "]");
}

4. Combining Decomposition with Object Modeling

Integrating a rich domain model with the phased decomposition yields a cleaner architecture, as illustrated by the system diagram (omitted). The methodology can be summarized as:

Top‑down structured decomposition of the workflow.

Bottom‑up object‑oriented analysis to build domain entities.

5. Capability Sinking

Rather than forcing every business rule into the Domain layer, the author proposes “capability sinking”: abstract reusable capabilities into the Domain only when they are needed across multiple use‑cases; otherwise keep them in the application layer.

Key metrics for sinking decisions are code reuse and cohesion.

Example domain entity CSPU encapsulates unit‑checking logic, eliminating scattered string comparisons.

public class CSPU {
    private String code;
    private String baseCode;
    // ... other fields

    /** Single product is the minimum unit */
    public boolean isMinimumUnit() {
        return StringUtils.equals(code, baseCode);
    }

    /** Special handling for mid‑package items */
    public boolean isMidPackage() {
        return StringUtils.equals(code, midPackageCode);
    }
}

6. Final Thoughts

The article concludes that business‑technology development is as challenging as core‑technology work. Mastering problem decomposition, abstraction, and structured thinking is essential for writing clean, maintainable code in complex domains.