In a classic three-tier layout where a `controller` package depends on a `service` package, which in turn directly imports concrete classes from a `repository` package that wraps the database, the code compiles and runs fine. Why is this still considered a dependency-direction problem, and how would you restructure the packages to fix it?

## The setup that compiles Picture three packages: `controller`, `service`, and `repository`, arranged so: - `controller` imports from `service` - `service` imports concrete classes from `repository` — say `OrderServiceImpl` directly holds a field typed `JpaOrderRepository` Every import statement resolves, the build succeeds, and requests flow correctly end to end. Nothing about this trips a compiler error, which is exactly why the problem is easy to miss: **dependency direction is a design property, not a syntactic one**, and the language happily lets you couple a stable layer to a volatile one. ## Why it still counts The reason this still counts as a dependency-direction problem is what the coupling costs you later, not whether it works today. `service` is meant to hold the rules that make the application what it is. `repository`, specifically the concrete `JpaOrderRepository`, is an implementation detail of how data happens to be persisted right now. By importing the concrete class, `service` inherits every constraint of that detail: - it needs a real or embedded database to be constructible at all - any change to the ORM's API surface is a compile error in business-logic code - there is no seam at which a test double can be substituted without reaching for a heavier mocking framework that mocks concrete classes (which is brittle — it breaks on refactors to methods the test never called) ## The fix The fix is the same inversion move regardless of language: 1. Define an interface that expresses only the operations the use case actually needs — not everything the concrete class happens to expose — and place that interface in or next to the `service` package. Something like `interface OrderRepository { findById(id): Order?; save(order) }`. 2. Rename the concrete class to implement it. `service` now has an import of `OrderRepository`, an interface it effectively owns, and zero imports of anything persistence-specific. 3. `repository`, in turn, imports `OrderRepository` from `service` in order to implement it — **the arrow has reversed**. A composition root (a configuration class, a manual wiring function, whatever the framework's entry point is) is the one place that knows about both the interface and the concrete implementation and wires them together; that file is allowed to violate the rule because its entire job is to bridge the two worlds. ## What it buys - **A unit test.** This is worth doing because it changes what a unit test looks like: testing `OrderService` now means providing a hand-written or generated fake `OrderRepository` (an in-memory map, for instance) with no database and no application context, running in milliseconds instead of seconds. - **A persistence migration.** It also changes what a persistence migration looks like: swapping the ORM, or adding a caching decorator around persistence, touches only the `repository` package and the composition root — `service` is untouched, because it never depended on the concrete detail to begin with. ## The nuance worth knowing There's a real nuance worth knowing, especially in Spring/JPA codebases: **Spring Data repository interfaces look like they already satisfy this pattern** because they're interfaces — but the base type they extend is itself a Spring Data library type, so the interface, even with no concrete JPA import, still carries a compile-time dependency on that library. For most teams this is an accepted, pragmatic compromise, but teams practicing strict hexagonal architecture sometimes add one more layer — a hand-rolled port interface with no framework supertype, implemented by an adapter class that internally delegates to the Spring Data interface — specifically to keep the use-case-facing interface framework-free. ## What it costs The restructuring isn't free: it adds a file, a rename, and a wiring step, and for a one-off script or a service that will only ever have one persistence technology, that ceremony buys little. But for any service expected to be unit-tested in isolation, evolve its persistence technology, or run against a fake/in-memory implementation in some environments, inverting this dependency is what makes those things possible without a rewrite.