Dependency inversion

What it means

Dependency inversion means that high-level behavior should not depend directly on low-level details when a stable contract can separate them. The detail and policy both depend on an abstraction, while composition supplies the concrete implementation. This can improve testing and change isolation when the boundary reflects a real responsibility.

Example

An order policy depends on a payment authorization port, while adapters implement that port for a provider and a test fake. The policy remains focused on business decisions rather than provider SDK calls.

Limitations

Adding an interface everywhere can obscure a simple design and create indirection without reducing change impact. The boundary should be justified by variation, ownership, or test needs.

How to use the signal

Add an abstraction only where it protects a real variation or ownership boundary, rather than creating indirection as a reflex.

Weave can help evaluate whether dependency-inversion changes affect review time and rework. Repository architecture tooling verifies direction; Weave provides context about how the refactor traveled through delivery.