How does the Dependency Inversion Principle change a design?

The Dependency Inversion Principle has two parts: high-level policy should not depend on low-level detail, and abstractions should not depend on details; details should depend on abstractions. In practice, business logic defines the interfaces it needs and infrastructure implements them.

Without DIP, an OrderService that directly instantiates MySqlOrderRepository is welded to MySQL and hard to test. With DIP, the service depends on an OrderRepository interface, and the concrete database class is injected.

interface OrderRepository { void save(Order o); }
class OrderService {
    private final OrderRepository repo;
    OrderService(OrderRepository repo) { this.repo = repo; }
    void place(Order o) { repo.save(o); }
}

This inverts the usual direction of dependency and enables unit tests with in-memory fakes. It is closely tied to dependency injection as the mechanism and to hexagonal architecture, which keeps the domain free of framework code.