Methodology for Writing Complex Business Code: Structured Process Decomposition and Domain Modeling

The article introduces a methodology for writing complex business code, using a real‑world retail product onboarding scenario to demonstrate how structured process decomposition and domain‑driven design can simplify intricate workflows.

It first outlines the business background of a B2B supply‑chain platform and describes the critical "on‑sale" operation, highlighting the need for clear process steps and data validation.

To manage complexity, the author advocates a top‑down decomposition of the overall use case into phases and steps, avoiding over‑reliance on heavyweight tools like workflow engines. The recommended approach follows a simple pipeline or composed‑method pattern.

Example code shows a command class that orchestrates three phases (init, data check, process) using injected resources:

@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 processing phase itself is broken into multiple steps, each handling a specific sub‑task such as generating offer numbers, publishing offers, binding stock, 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);
    }
}

Beyond process decomposition, the article stresses the importance of introducing a domain model to replace scattered conditional logic. A simplified model example shows how polymorphism can eliminate many if‑else checks:

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

    public boolean isMinimumUnit() {
        return StringUtils.equals(code, baseCode);
    }

    public boolean isMidPackage() {
        return StringUtils.equals(code, midPackageCode);
    }
}

The author argues that combining process decomposition with a well‑designed object model yields clearer, more maintainable code, and introduces the concept of "capability sinking"—moving reusable functionality into the domain layer only when it proves valuable across multiple use cases.

Finally, the article reflects on the broader challenges faced by business‑technology engineers, emphasizing that strong abstraction, structured thinking, and domain modeling skills are essential for tackling complex business logic as effectively as low‑level technical problems.