Overview of System Complexity and Strategies for Reducing Business Complexity

1. What is complexity – Complexity in software design is the difficulty of understanding and maintaining code; there is no single definition, but a formula by Stanford professor John Ousterhout relates module complexity (cp) and development time weight (tp) to overall system complexity (C).

2. Complexity classification – The article focuses on business complexity and its governance, illustrating different categories with diagrams.

3. Impact of high business complexity

Higher R&D cost due to more time needed for understanding and maintaining code.

Reduced stability because complex logic is error‑prone and changes can cause cascading failures.

4. Common reasons for high business complexity

Many inter‑dependent modules (e.g., e‑commerce systems with orders, inventory, finance, etc.).

Obscure code that hides key logic, making it hard to grasp without diving into methods.

Frequent and varied business rule changes.

Code examples illustrate unclear implementations:

/**
 * 处理业务逻辑
 */
public void handleBiz() {
    step1();
    step2();
    step3();
}

/**
 * 转换对象方法
 */
public Po convert(Dto dto) {
    Po po = new Po();
    po.field = dto.filed;
    // 更新操作，不应该放到转换方法里
    mapper.update(po);
    // 调用rpc服务，不应该放到转换方法里
    XXGateway.update(dto);
    return po;
}

5. Methods to reduce business complexity

5.1 Abstract divide‑and‑conquer

Split complexity by domain:

Domain splitting – extract core concepts into independent domains (e.g., product, user, address services).

Within‑domain splitting – separate immutable capabilities from variable business logic (e.g., marketing coupon engine).

Sub‑domain/system internal splitting – layer code, enforce clear responsibilities, avoid cross‑layer calls.

5.2 Structured top‑down decomposition

Apply the pyramid principle to break down complex processes into hierarchical steps, illustrated with a pseudo‑code example:

public void setUp() {
    // 参数检查阶段
    paramCheck();
    // 初始化阶段
    initData();
    // 业务校验阶段
    businessCheck();
    // 业务执行阶段
    businessExecute();
}

5.3 Add meaningful comments

Comments should explain the *what* and *why*, not just the *how*, and can reference external design documents when needed.

5.4 Configuration

Configurable business objects (e.g., SKU attributes).

Configurable business rules using rule engines such as Aviator, Drools, QLExpress.

Configurable business flows via workflow frameworks (e.g., Alibaba TMF, Meituan BPF, JD Logistics Batrix).

5.5 Coding standards and architectural conventions

Consistent naming (e.g., OrderDao clearly indicates its purpose).

Layered architecture with clear direction of calls (upper layers call lower layers only).

Consider merging tightly coupled systems to reduce cross‑module impact.

The article concludes with refactoring principles: small incremental deliveries, write‑then‑read migration, and tackling light logic before heavy logic.