Dependency Inversion Principle: Why Business Logic Should Not Know Its Tools

The Dependency Inversion Principle (DIP) states that high-level business modules should not depend directly on low-level tools or external services, but instead rely on abstract interfaces. A common violation occurs when a use case class directly instantiates an external provider, tightly coupling business logic to a specific implementation. The recommended fix is to define a generic interface within the application's own domain and inject the dependency through the constructor, a pattern known as Dependency Injection. This approach means swapping one email provider for another, for example SendGrid for AWS SES, requires no changes to the core business class. An added benefit is that unit testing becomes simpler, as fake mock implementations can be injected without triggering real external calls.