Skip to content

Dependency Inversion Principle

High-level modules should not depend on low-level modules; both should depend on abstractions, because dependency direction determines which components can change independently.

Tension Addressed

Flexibility vs. Simplicity

Recognizable As

Business logic depending on repository interfaces not database clients; policy modules defining interfaces that detail modules implement; "ports and adapters" structure

Canonical Sources

Martin, "The Dependency Inversion Principle" (1996); Cockburn, "Hexagonal Architecture" (2005)

Transfers To

Software Architecture (layered dependencies), Testing (injectable dependencies), Plugin Systems

The inversion is in control: instead of high-level policy adapting to low-level detail, detail adapts to policy-defined interfaces. This protects stable business logic from volatile infrastructure changes.