Dependency Rule

The fundamental organizing principle of clean architecture that governs how software components can depend on each other. The rule states that source code dependencies can only point inwards toward higher-level abstractions.

Core Constraints

Inward-Only Dependencies

• Nothing in an inner circle can know anything about an outer circle
• Names of outer circle entities (functions, classes, variables) must not be mentioned in inner circles
• Data formats from outer circles cannot be used by inner circles
• Frameworks in outer circles cannot influence inner circle design

Abstraction Hierarchy

As you move inward through the concentric circles:

• Software becomes more abstract and policy-oriented
• Level of abstraction increases from concrete details to general principles
• Inner circles are more general and stable
• Outer circles contain mechanisms and implementation details

Boundary Crossing Mechanics

When control flow must cross boundaries in a direction that would violate the dependency rule, the dependency inversion principle resolves the contradiction:

1. Interfaces in Inner Circles — Define contracts that outer circles implement
2. Dynamic Polymorphism — Allows source dependencies to oppose control flow direction
3. Simple Data Structures — Cross boundaries without carrying framework dependencies

Example Pattern

Use case needs to call presenter:

• Use case calls interface (Use Case Output Port) in its own layer
• Presenter in outer layer implements that interface
• Source dependency points inward (rule satisfied)
• Control flows outward (functionality achieved)

Data Crossing Rules

Data crossing boundaries must be:

• Simple structures — DTOs, function arguments, basic objects
• Free of dependencies — No framework types or database rows
• Convenient for inner circle — Format optimized for business rule consumption

Anti-pattern: Passing database framework RowStructure inward violates the rule by forcing inner circles to know about outer circle data formats.

Architectural Benefits

Enforcing the dependency rule creates:

• Testable systems — Business rules isolated from external dependencies
• Replaceable components — Outer layers changeable without affecting inner logic
• Stable core — Business rules protected from technological churn
• Clear separation — Policies distinct from mechanisms

The dependency rule is the key constraint that enables clean architecture’s independence guarantees.

[source: uncle-bob-clean-architecture-2012]