The DIP states that one should depend upon abstractions. Do not depend upon concretions. In other words, high-level modules should be decoupled from low-level modules through abstractions. This principle states that code should be structured around the problem domain, and the domain should declare dependencies on required infrastructure as protocols. Dependencies thus point inward to the domain model.

The reason that this principle is an inversion is because typical architectures promoted by OOP (via layer architecture) exhibit dependency graphs, where high-level modules consume low-level modules directly.

Initially, this dependency graph seems natural as, in expressing domain models in code, one inevitably depends upon the constructs of the language. Procedural programming allows dependencies to be encapsulated by procedures.

Subtype polymorphism defers procedure implementation. Unfortunately, the use of protocols is often overlooked to express domain dependencies in OOP implementations. Given that infrastructure code is typically more voluminous, the focus of the code drifts away from the domain. DDD was devised in part to balance this drift.