The direction of the arrow
Take an order service that needs to save orders to Postgres. The obvious structure has OrderService importing PostgresOrderRepository, so the dependency arrow points from policy to detail: the business logic knows about the database.
That arrangement has a specific problem, and it is not primarily about testing. It is that the thing you care most about protecting — the rules of the business, which are the reason the software exists — is now downstream of the thing most likely to change for reasons that have nothing to do with the business. Swap the database and you recompile the order logic.
Inverting means OrderService declares what it needs, as an interface, and PostgresOrderRepository implements it. The arrow from the concrete class now points up at the abstraction, and the high-level module points at nothing below it.
What inverts is ownership
The part that separates a memorised answer from an understood one: the interface belongs to the consumer.
OrderRepository is not the database layer's public API. It is the order service's statement of its own requirements, expressed in the order service's language, and it lives in the order service's package. The persistence module imports it in order to implement it. That is why the source dependency reverses — the arrow at build time now runs from the detail toward the policy, the opposite of the runtime call direction.
Put the interface in the persistence package and you have achieved nothing structural. The high-level module still imports the low-level one; you have simply put an interface in the way, and every consumer still recompiles when the persistence package changes. This is the most common way the principle is applied wrongly, and it is invisible unless you look at which package the file sits in.
The consequence follows in the method signatures. If OrderRepository exposes findByCriteria(SqlPredicate) or returns a database cursor, the abstraction has leaked and the inversion is cosmetic — the caller is still coupled to the storage model, just through one more layer. A repository owned by the domain speaks in domain terms: findUnfulfilledOrdersFor(CustomerId).
Inversion is not injection
These get conflated constantly and they are different things at different levels.
Dependency inversion is about which direction the source dependency points, and it is a structural property you could check by looking at the import graph. Dependency injection is a technique for supplying a collaborator from outside rather than constructing it internally. You can inject a concrete class, which is injection without inversion. You can invert and then instantiate the implementation in a factory with no container anywhere, which is inversion without a framework.
A candidate who answers "dependency inversion means using a DI container" has named a tool and missed the principle.
When not to bother
The honest limit. An interface with one implementation, no prospect of another, and no test that needs to substitute it is a file you maintain for nothing. Every call now needs one extra jump to read, and the navigability cost is real in a large codebase.
The useful test is whether the boundary is one across which change genuinely arrives. Persistence, third-party APIs, clocks, message brokers, anything with a network or a vendor behind it — these change on someone else's schedule and are worth insulating. An internal PriceCalculator used in one place, changing only when the business rules change, is not: the interface would just be a copy of the class, and when the rules change you will change both.
Testability is a legitimate reason to invert on its own, and it is worth saying so directly rather than pretending the second implementation is coming. A fake repository that a unit test can drive is a real second implementation, and it justifies the abstraction by itself.
The interface is owned by the code that uses it, expressed in that code's vocabulary. Put it in the implementer's package and you have written an abstraction without inverting anything.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).