How to Tame Business System Complexity: Strategies and Best Practices

What Is Complexity?

Software design aims to reduce complexity. There is no single definition, but Stanford professor John Ousterhout proposes a formula based on cognitive load and work effort.

Complexity of a sub‑module (cp) multiplied by its development‑time weight (tp) summed across modules yields the overall system complexity (C). The sub‑module complexity is an empirical value, and rarely‑used complex code may have little impact on the total.

Complexity Classification

The focus is on managing business‑level complexity.

Impact of High Business Complexity

Higher R&D cost: more time to understand and maintain code, more changes required.

Poor stability: difficult to comprehend, leading to errors and regressions.

Common Causes of High Business Complexity

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

Obscure code that hides key logic.

Frequent changes in business rules and processes.

Methods to Reduce Business Complexity

1. Abstract and Divide

Domain Splitting

Separate concerns into independent domains such as entity services (product, user), workflow services (supply‑chain, approval), and computation services (search, recommendation).

In‑Domain Splitting

Separate stable (unchanging) parts from volatile ones, and isolate scenarios (e.g., B‑side vs. C‑side).

2. Internal Sub‑System Splitting

Apply layered architecture: access layer (logging, validation), business logic layer, domain service layer, and data layer, ensuring each layer has a single responsibility and no cross‑layer calls.

3. Structured Top‑Down Decomposition

Use the pyramid principle to break complex processes into hierarchical steps, as illustrated by the QR‑code installation workflow example.

4. Method‑Level Refactoring

Keep methods single‑purpose with clear, accurate names.

5. System Consolidation

Merge tightly coupled systems to reduce ripple effects of changes.

6. Add Meaningful Comments

Comments should explain the *what* and *why*, not just the *how*, and may include links to design documents.

7. Configuration‑Driven Design

Make repeatable business objects, rules, and workflows configurable via a central configuration center or rule engine (e.g., Aviator, Drools, QLExpress).

8. Use Standards to Lower Complexity

Adopt naming conventions, architectural layering rules, and clear module boundaries to simplify reasoning.

Practical Examples

Code snippets demonstrating poor and good practices:

/**
 * Process business logic
 */
public void handleBiz() {
    step1();
    step2();
    step3();
}

/**
 * Convert DTO to PO and avoid side‑effects
 */
public Po convert(Dto dto) {
    Po po = new Po();
    po.field = dto.field;
    // Do NOT perform updates or RPC calls here
    return po;
}

Illustrations