Understanding and Controlling Software System Complexity

Complexity Definition

A complex system consists of many interacting parts that are relatively simple individually, lack central control, and have no global communication, yet their interactions produce complex behavior. In software, functions, classes, modules, components, and services act as parts whose interactions lead to overall system complexity.

Causes of Complexity

Examples illustrate how comprehension ability and predictability describe complexity across domains such as underwear, watches, small teams, cities, double pendulums, and the stock market.

Software System Complexity Analysis

Software systems are both "hard to understand" and "hard to predict," similar to city construction. The analysis considers two dimensions: comprehension ability and predictability.

Comprehension Ability

Scale Analysis

System scale growth depends not only on the number of requirements but also on the relationships between functional points. Elements for evaluating scale include code lines, number of packages/classes/methods, inheritance depth, method call count, and cyclomatic complexity.

Functions with side effects and hidden assumptions.

Classes with many responsibilities, making developers reluctant to modify them.

Hotspot code that changes frequently and accumulates layers of responsibility.

Hidden bugs that trigger under obscure conditions.

Diverse exception handling across business scenarios.

Mixing synchronous and asynchronous code, leading to unpredictable call order.

Structural Analysis

Complexity often stems from a system's quality attributes. From monolithic to distributed micro‑services, the evolution reflects continual decomposition. Conway's Law states that system structure mirrors the organization’s communication structure.

Elegant design actively controls structural complexity, whereas poor design introduces accidental, unordered complexity (technical debt).

Typical symptoms of unordered design include lack of clear entry points, inconsistent style, unpredictable control flow, many code smells, and misplaced data or overused caching.

Predictability

Predictability is challenged by change; inability to foresee future changes makes software unpredictable, leading to over‑design or under‑design.

Over‑Design Manifestations

Introducing unnecessary abstractions to guarantee scalability.

Under‑Design Manifestations

Failing to identify inevitable future changes or lacking foresight on requirement evolution.

How to Control Software Complexity

Controlling Scale

Domain‑Driven Design (DDD) tackles complexity by improving design quality and decomposing large systems into small, bounded contexts and context maps during strategic design.

Clear Structure

Separating business logic from technical implementation establishes clear boundaries, following the principle of separation of concerns. DDD introduces layered architecture: the domain layer encapsulates business logic, the infrastructure layer supports it, and the application layer acts as a façade and coordinates collaboration.

This separation yields an orderly design.

Responding to Change

Locking change into a controlled “cage” via patterns and abstractions limits variability to manageable scopes, enabling rapid detection and minimal adaptation when changes occur.

Domain modeling abstracts dispersed concerns into a unified model, visualizing complex business and allowing incremental changes to be identified and addressed with minimal cost.

Architect Community Group

The author has created an architect community group; readers can add the editor on WeChat to join and share ideas.

Scan the QR code to add the friend and request to join the group, indicating name, company, and position.