Dependency Inversion
The rule that high-level policy should not depend on low-level detail, both depending instead on an abstraction owned by the policy.
The most architecturally significant of the SOLID principles, and the one that scales beyond classes to services and systems.
Stated concretely: an order service should not import a PostgreSQL client. It should define an
OrderRepository interface expressing what it needs, and a separate adapter should implement that
interface using PostgreSQL. The interface belongs to the policy, not to the implementation — that
ownership detail is what makes it inversion rather than merely indirection.
What it buys: the business logic can be tested without a database; the persistence technology can be replaced without touching the domain; and the domain code stays free of framework and vendor concepts.
What it costs: an extra layer, and a genuine risk of over-application. An interface with exactly one implementation, created speculatively, is indirection without benefit — and a codebase where every class has a matching interface is harder to read, not more flexible.
The judgement is whether the dependency is volatile and foreign: a database, an external API, a message broker, a clock, a random source. Those warrant inversion. A stable internal utility does not.
This is the same principle that appears as the dependency rule in clean architecture and as ports and adapters in hexagonal architecture.