The Dependency Inversion Principle

Dependency in layered architecture

In our layered architecture, the cross-layer dependencies always point downward to the next layer. When we apply the Single Responsibility Principle on a high level, we notice that the upper layers have more reasons to change than the lower layers.

Thus, due to the domain layer’s dependency to the persistence layer, each change in the persistence layer potentially requires a change in the domain layer. But the domain code is the most important code in our application! We don’t want to have to change it when something changes in the persistence code!

How can we get rid of this dependency?

The Dependency Inversion Principle provides the answer.

In contrast to the SRPSingle Responsibility Principle, the DIPDependency Inversion Principle means what the name suggests:

We can turn around (invert) the direction of any dependency within our codebase$^3$.

Actually, we can only invert dependencies when we have control over the code on both sides of the dependency. If we have a dependency to a third-party library, we cannot invert it as we don’t control the code of that library.

How does it work?