Understanding Business Complexity and the Value of Domain‑Driven Design

The origin of business complexity is traced to the subtitle of Eric Evans' book *Domain‑Driven Design*: "Tackling Complexity in the Heart of Software." The article identifies two main causes: scale and domain logic.

1.1 Scale‑related complexity – No precise metric exists for when a system is large enough to be considered complex, but the practical indicator is when the system must be decomposed to control complexity. The width (number) of business units, such as use cases or services, reflects this scale.

1.2 Domain‑logic complexity – Depth of business units, measured by the levels in a task‑tree from root to leaf, indicates complexity. A task is considered atomic if it either requires knowledge owned by a single aggregate or accesses external resources; otherwise it should be further decomposed.

2. Value of Domain‑Driven Design (DDD) – DDD introduces design patterns and principles aimed at fighting software complexity.

2.1 Subdomain division – By partitioning the problem space into subdomains (core, generic, supporting), teams can prioritize based on ROI and limit the scale‑induced complexity.

2.2 Bounded‑context division – Similar to subdomains, bounded contexts split the solution space, providing autonomous architectural units that also define the boundaries of the domain model.

2.3 Controlling object size and dependencies – Bounded contexts prevent the creation of monolithic domain classes, reducing unnecessary coupling between modules.

2.4 Business‑technology orthogonality – Maintaining a clear separation between business logic and technical implementation (e.g., via a diamond‑shaped symmetric architecture) isolates business complexity from technical complexity.

2.5 Consistent code model – Adopting a uniform code model across teams (remote services, local services, domain services, aggregates, ports) improves understandability and reduces maintenance effort.

2.6 Aggregates as abstraction – Aggregates encapsulate domain logic, enforcing that only aggregate roots can be accessed externally, thereby limiting the proliferation of domain objects and simplifying the model.

2.7 Strategic vs. tactical design – Strategic design addresses width‑related complexity, while tactical design tackles depth‑related complexity; teams can choose either independently based on the problem space.