Comparison
Dependency inversionvsSOLID
Dependency inversion
the business rules import the Postgres driver, so testing a discount calculation needs a database.
Making the important code depend on an interface it defines, and the infrastructure depend on that interface too, so the arrow points inward instead of outward. The practical effect is that the rules of your business can be tested and understood without a network, a database or a cloud account. It is the backbone of the ports-and-adapters argument, and the reason a senior engineer will push back on a domain object that knows what a HTTP status code is.
Full entry →SOLID
someone rejected the pull request citing a five-letter acronym, and only two of the five letters were actually about the problem.
Five object-design principles collected under one acronym: single responsibility, open–closed, Liskov substitution, interface segregation and dependency inversion. Taken individually they are useful heuristics with genuine failure modes to point at; taken as a checklist they are the most reliable way to talk a team into more indirection than it needs. Being able to name all five and say honestly which ones you find load-bearing is a better interview answer than reciting them.
Full entry →