Dependency direction

Dependency direction means high-level policy does not depend on low-level details. Infrastructure, frameworks, and databases are details; business rules should sit at the center and receive collaborators through abstractions. The Dependency Inversion Principle is the architectural spine behind ports, adapters, and testable services.

On interviews: draw a quick diagram with arrows pointing inward. Contrast importing ORM entities into domain code versus defining repository interfaces in the domain/application layer.

Common pitfalls: framework annotations on domain classes; circular dependencies between modules; "interfaces everywhere" with no real substitution point.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• List what is policy versus detail in your example system.
• Show how tests swap infrastructure with fakes.
• Keep volatile dependencies behind narrow ports.
• Enforce direction with module boundaries or lint rules.