Controlling Dependencies with Bounded Contexts and Aggregates in Domain‑Driven Design

Software complexity originates from three sources: scale, structure, and change. While splitting a large system into smaller elements mitigates scale complexity, it increases structural complexity; uncontrolled structure amplifies the impact of change, making dependency control essential.

Two practical strategies for dependency control are proposed: (1) reduce the number of dependencies by allocating responsibilities wisely ("many to few"), and (2) weaken the strength of unavoidable dependencies through encapsulation and abstraction ("strong to weak").

At the strategic level, a Bounded Context serves as a knowledge boundary and a vertical slice of business capability, providing a clear scope for domain knowledge and limiting unnecessary cross‑module dependencies.

An illustrative example shows how different departments (HR, Finance, Project Management) view an employee's data through their own bounded contexts, each receiving only the information relevant to its concerns, thereby reducing coupling.

Compared with traditional module decomposition, bounded contexts allocate domain knowledge to the contexts that need it, eliminating the need for other modules to depend on unrelated elements.

At the tactical level, Aggregates enforce a tree‑structured model with a single root entity, ensuring that internal domain objects are encapsulated and that relationships across aggregates are only established via the root, thus limiting intra‑model dependencies.

Together, bounded contexts (strategic) and aggregates (tactical) embody the principle of high cohesion and low coupling, offering concrete methods to manage dependencies in complex systems.

The autonomy of a bounded context is defined by four characteristics: minimal completeness, self‑fulfillment, a stable space that isolates external change, and independent evolution that hides internal models behind gateways.

The autonomy of an aggregate is described by four traits: completeness (a minimal, cohesive domain concept), independence (separate lifecycle), invariants (business rule enforcement), and consistency (data and lifecycle integrity).

By applying these autonomy principles, Domain‑Driven Design provides a practical pathway to reduce both the quantity and intensity of dependencies, achieving a robust, maintainable architecture.