SOLID Principles

Definition

Single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion. Formulated for object-oriented design, and of uneven value at architectural scale.

Which ones matter architecturally

Dependency inversion is the one with real structural consequence. High-level policy should not depend on low-level detail; both should depend on an abstraction. In practice: the domain defines the interface it needs (OrderRepository), and the infrastructure implements it. The dependency arrow points inward, toward the stable thing.

That single rule is what makes hexagonal and clean architecture work, what makes a database replaceable, and what makes the domain testable without infrastructure. Everything else in the acronym is a coding guideline by comparison.

Interface segregation matters at service boundaries: a consumer should not be coupled to methods it does not use. This is the same instinct that makes consumer-driven contracts declare only the fields actually used.

Single responsibility is useful when stated correctly — "one reason to change", which is really about change correlation, the same test that identifies a good service boundary. It is useless when misread as "do one thing", which justifies splitting everything into pieces that must always change together.

Where SOLID misleads

Open/closed, taken literally, produces speculative extension points — abstract factories and strategy interfaces with one implementation, added for a variation that never arrives. That is premature abstraction with an acronym behind it.

Liskov is largely subsumed by preferring composition over inheritance, which most modern codebases already do.

The honest position

SOLID is a set of heuristics for managing coupling in object-oriented code, and it is frequently recited as though it were an architecture. The architectural content is: point dependencies at stable abstractions, and put boundaries where change correlates. The rest is craft.

Failure scenarios

• Interfaces with one implementation, forever — indirection with no option value.
• Single responsibility read as "small", producing a hundred classes that always change together.
• Applied as a code-review checklist, where it generates ceremony rather than better structure.

Interview question

"Which SOLID principle has architectural consequences, and what does it enable?"