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

When faced with intricate business scenarios such as the product‑on‑sale workflow in a B2B retail platform, the author proposes a systematic approach that first breaks the process into clear phases and then maps each phase to well‑defined domain objects.

Process decomposition is illustrated with three phases (initialization, data‑check, processing) represented by a command class:

@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);
    }
}

Each Phase can be further split into Step classes, for example the OnSaleProcessPhase contains steps such as PublishOfferStep , BackOfferBindStep , and others, each encapsulating a single business action.

The article argues against over‑using heavy tooling like workflow engines; instead it recommends a simple pipeline or, ideally, no extra tool at all (KISS principle). By keeping the code structure explicit, readability and maintainability improve dramatically.

After demonstrating the procedural version, the author shows how introducing a proper domain model eliminates most conditional logic. For instance, a CSPU entity encapsulates methods like isMinimumUnit() and isMidPackage() , removing scattered string comparisons:

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

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

    /** Whether the SKU is a mid‑package */
    public boolean isMidPackage() {
        return StringUtils.equals(code, midPackageCode);
    }
}

With polymorphic domain objects (e.g., CombineBackOffer extends BackOffer ), the complex if‑else checks disappear, and the business rules become expressive through method calls.

The author further introduces the concept of "ability sinking" – abstracting reusable capabilities into the Domain layer only when they are needed across multiple use‑cases, otherwise keeping them in the application layer. This balances domain purity with pragmatic reuse.

Finally, the piece reflects on the role of "business‑technology" engineers, emphasizing that solid fundamentals in object‑oriented design, modeling, and abstraction are essential for both business‑centric and low‑level system development.