Dependency Inversion Principle

Overview

The Dependency Inversion Principle (DIP) says high-level policy should not depend on low-level details; both should depend on abstractions, and the abstractions should be owned by the high-level side. OrderService should depend on a PaymentGateway interface it defines, not on StripeClient directly.

DIP 'inverts' the usual direction: the database or vendor module depends on the business module's interface, not the other way around. This makes business logic testable with fakes, lets infrastructure be swapped, and is the foundation of clean and hexagonal architecture. Dependency injection is the usual technique for supplying implementations.

When to use it

• Business logic calls databases, networks, clocks, or vendors.
• You need unit tests without real infrastructure.
• Infrastructure may change (database, cloud provider, vendor).

Where it shows up in interviews

Where it is used in real software

Key terms

High-level module

Business policy (OrderService).

Low-level module

Details (Postgres repository, HTTP client).

Abstraction ownership

The interface lives with the high-level module.

Dependency injection

Passing dependencies in rather than creating them.

Composition root

The one place where concrete classes are wired together.

How it works, step by step

1. 1
   Find direct dependencies on details

   new StripeClient() inside business code.

2. 2
   Define an interface in the business layer

   PaymentGateway.charge().

3. 3
   Implement it in the infrastructure layer

   StripePaymentGateway.

4. 4
   Inject through the constructor

   OrderService(gateway).

5. 5
   Wire at the composition root

   main(), DI container, or module setup.

Dependency direction

OrderService needs to charge cards and save orders

Business code becomes the stable center; details plug into it.

Implementation

1// Business layer owns the abstractions2export interface PaymentGateway { charge(customerId: string, cents: number): Promise<string> }3export interface OrderRepository { save(order: { id: string; paymentId: string }): Promise<void> }4export interface Clock { now(): Date }5 6export class OrderService {7  constructor(private payments: PaymentGateway, private orders: OrderRepository, private clock: Clock) {}8  async place(id: string, customerId: string, cents: number) {9    if (this.clock.now().getUTCHours() === 3) throw new Error("Maintenance window");10    const paymentId = await this.payments.charge(customerId, cents);11    await this.orders.save({ id, paymentId });12    return paymentId;13  }14}15 16// Test with fakes: no network, no database, deterministic time17const saved: unknown[] = [];18const service = new OrderService(19  { charge: async () => "pay_1" },20  { save: async (o) => { saved.push(o); } },21  { now: () => new Date("2026-01-01T10:00:00Z") },22);

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Interfaces defined next to the implementation in the infrastructure layer.

  Fix: The consumer (business layer) should own the interface.

• new-ing dependencies inside business classes.

  Fix: Inject them.

• Using system time and randomness directly.

  Fix: Inject Clock and random sources.

Interview questions

Practice problems