What is the essence of the Dependency Inversion Principle (DIP), and how does it differ from Dependency Injection (DI)?

Short answer

DIP is an architectural principle requiring both high-level modules and low-level details to depend on abstractions. DI is a coding pattern for passing dependencies from outside.

Explanation

In a traditional architecture, the business layer (high-level business logic) directly depends on the data layer (SQL database client). DIP reverses this direction: the business layer defines an abstraction (a port or contract) that meets its needs, and the data layer implements it (an adapter). Business rules then become independent of database or cloud-provider details.

Code example

// The business layer owns the contract:
interface NotificationSender {
  send(message: string): Promise<void>;
}
// The business layer depends on the abstraction:
class OrderService {
  constructor(private notifier: NotificationSender) {}
}

Common mistakes

• Believing that using libraries such as Inversify or Dagger automatically applies DIP, when the principle is really about who owns the interface and the direction of architectural dependencies.

Follow-up questions

• What is the true meaning of the Single Responsibility Principle (SRP), and how do you identify a "responsibility"?

Sources

• Dependency inversion principle - Wikipedia