The Dependency Inversion Principle is not free. What criterion decides which dependencies are worth inverting, and where does over-applying it hurt an architecture?

## The criterion: volatility, not "level" People apply DIP by layer diagram ("domain must never touch infrastructure") and then find themselves wrapping `String`, `List`, and the date library. The sharper rule, stated by Robert Martin among others, is: **depend directly on things that are stable; invert dependencies on things that are volatile.** A dependency is *volatile* when any of these apply: - It changes for reasons unrelated to your business rules (vendor releases, framework upgrades, ops decisions). - It reaches outside the process: network, disk, database, message broker, external API. - It is non-deterministic: clock, random, UUID generation, environment. - It is not fully built/decided yet, or is owned by another team with its own release cadence. - Several variants are plausible: multi-cloud, multi-tenant, region-specific rules, a strangler migration. A dependency is *stable* when it changes rarely, changes compatibly, and would never realistically be substituted: primitives, collections, mature standard-library facilities, pure math, your own value objects. ## Sibling principles at component scale - **Stable Dependencies Principle (SDP)**: depend in the direction of stability. A component with many dependents is hard to change; it should depend on things even harder to change. - **Stable Abstractions Principle (SAP)**: a component that is stable (many dependents) should be *abstract*, so it can be extended without modification; a volatile component should be concrete. DIP is the class-scale mechanism by which SDP+SAP are achieved. Together they explain why an interface-only "contract" module can be depended on by everyone: it's maximally stable *and* maximally abstract, so it doesn't imprison anyone. ## The costs, itemized 1. **Indirection tax.** Every port adds a type, a file, and a navigation hop. At scale, comprehension and debugging slow down; a stack trace of proxies and adapters is materially harder to read. 2. **Compile-time → runtime error migration.** With wiring done by a container or config, a missing or ambiguous binding surfaces at startup (or worse, on first request) rather than at compile time. Mitigations: pure DI with a compile-checked composition root, compile-time DI (annotation-processor based), or startup self-checks that resolve the whole graph eagerly. 3. **Premature/wrong abstraction.** An interface designed against exactly one implementation almost always encodes that implementation's assumptions — its error model, its transaction semantics, its paging behaviour. The second implementation then doesn't fit and the abstraction is either mangled or bypassed. 4. **Lowest-common-denominator ports.** To keep a port implementable by every candidate technology you strip out what makes each good: bulk upserts, native full-text search, streaming, cursor paging, database-side aggregation. Result: a portable but slow system, portable to a database you will never adopt. Often the honest choice is to commit to a technology and depend on it directly in a well-contained module. 5. **Leaky semantics.** Failure modes, ordering guarantees, idempotency and transactionality are part of a contract but rarely written into an interface. Adapters silently differ, and the policy that was "decoupled" breaks when the adapter is swapped. If a port has semantics, they must be specified *and* covered by a shared contract test suite that every adapter runs. 6. **Organizational cost.** More modules means more build wiring, more review surface, more onboarding, sometimes cross-team negotiation for contract changes. ## The counter-costs of *not* inverting Don't over-rotate. Under-inversion produces: business logic that cannot be tested without infrastructure (slow, flaky suites), a core that recompiles on every driver bump, vendor lock-in that only reveals itself during a migration, and an inability to run the system locally or in CI without external services. Those are usually more expensive than a handful of ports. ## Practical heuristics used by experienced architects - **Invert at I/O boundaries by default.** Anything crossing the process boundary gets a port; the test fake alone repays it. - **Do not invert inside a cohesive module.** Classes that change together, ship together, and are owned by one team should just call each other. - **Prefer few, wide-value boundaries over many thin ones.** Boundaries are expensive; place them where change actually happens. - **Wait for the second implementation** for anything that is not clearly at a boundary; extraction later is a mechanical refactor. - **Write contract tests** for every port so all adapters are held to the same behaviour. - **Enforce direction mechanically** (architecture tests / module boundaries) rather than by convention. - **Reassess.** A dependency's volatility changes over time; a boundary that stopped paying rent can be collapsed. ## A useful framing An abstraction is a bet that a particular axis of change will occur. Placing many bets is not free; each one costs comprehension and constrains capability. Senior judgment is picking the few axes where change is likely or where the testability payoff is immediate — and being willing to remove a boundary that never paid off.