An important characteristic of good design is the ability to contain the ripple effects of code changes. The inability to do so leads to rigidity where changes in one module necessitate adjustment in others. Rigidity makes code change difficult, risky, and expensive. Dependency inversion is an architectural design pattern that helps minimize rigidity and promotes highly flexible software.
Typically, a caller invokes a function by providing the necessary arguments and handling the return. When a function is designed independently from how it will be called, callers are forced to follow (i.e. depend on) the function's API. The dependency flows from caller (depends on) to callee (depended on).
Changing the callee's API, in this case, will break the caller. This means whenever the callee API changes, a corresponding change in the caller is necessary. To make things worse, the callee could be an external/3rd party library (no control over change) and there are several callers using it (widespread impact). When breaking changes are unhedged in this way, it typically results in more work and a higher risk of regression.
Dependency inversion helps in this situation by decoupling the caller and callee. Rather than the caller depending on callee API, both are made to depend on a common interface. This involves a subtle but crucial shift in the callee design which must now consider how it will be called. The callee must depend on the interface rather than being depended upon, reversing the dependency flow.
The introduction of a common interface ensures usability and prevents breaking changes. It provides a boundary that prevents changes from rippling uncontrolled from callee to caller. This has profound effects on the flexibility of the system allowing lower level details (e.g. I/O processing), which are typically callees, to freely change without affecting the structure of higher level policies (e.g. codified business rules), the callers. Dependency inversion protects the most valuable areas of the system concerned with the business from changes in more peripheral areas concerned with I/O or business-agnostic processes.