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

Software complexity stems from three sources: scale, structure, and change. While dividing a system reduces scale complexity, it can increase structural complexity, and poorly managed structure amplifies the impact of change.

Dependency control is crucial; dependencies are inevitable technical debt that, if unchecked, cause architectural decay over time.

Two viable strategies for managing dependencies are:

Reduce the number of dependencies by allocating responsibilities wisely ("from many to few").

Weaken the strength of unavoidable dependencies through encapsulation and abstraction ("from strong to weak").

Domain‑Driven Design (DDD) introduces bounded contexts and aggregates to address these strategies. A bounded context defines a knowledge boundary and a vertical slice of business capability, allowing each context to own the knowledge it needs without unnecessary external references.

Examples illustrate how different departments view the same employee data differently, and how bounded contexts isolate these views, eliminating cross‑departmental dependencies.

Aggregates further balance model granularity and dependency by grouping related entities and value objects under a single root entity, enforcing rules such as a single root, tree structure, and interaction only through the root.

Both bounded contexts (strategic layer) and aggregates (tactical layer) enforce autonomy: bounded contexts achieve minimal completeness, self‑fulfillment, stable space, and independent evolution; aggregates ensure completeness, independence, invariants, and consistency.

By applying these principles, architects can realize the classic "high cohesion, low coupling" guideline, making DDD a practical method for reducing dependency quantity and strength.