Originally, Uncle Bob did not teach these principles in the order people know today. His friend Michael Feathers, the author of Working Effectively with Legacy Code, pointed out that if you arrange them in a certain sequence, you get the word SOLID. That sequence is what we ended up learning.

The problem is the order itself

The idea should start with D. Inverting the dependencies or, the dependency rule. High-level policy must not depend on low-level details.

High-level policy is the business rules, the reason the system exists. Low-level details are the database, message broker, third-party frameworks, and delivery channels like Web APIs or desktop UIs.

Once D is set correctly, O and L are consequences. The system becomes open for extension and closed for modification because you can swap a message broker without modifying the core. As such, you can replace a concrete implementation at runtime without changing the code. That’s Liskov substitution.

These are not principles you apply first; they emerge when dependencies point in the right direction.

The I principle often drives systems toward shallow modules. Instead of one deep abstraction, you get fragmented contracts that push responsibility back to the caller. The shallow modules is taken from A Philosophy of Software Design book.

When interface segregation is applied mechanically, it creates coordination code. Over time, especially in large teams, this leads to brittle designs where complexity is spread everywhere instead of being contained.

The most ambiguous part is S. Most people think it means a class should do one thing. This confusion is reinforced by Clean Code, where the same author says code should do one thing and do it well. What becomes clear when reading Clean Architecture book is that S is not a code-level thing.

When decomposing a system into components, the idea is to look for sources of change. A source of change can be an admin, a retail user, a support agent, or an HR role.

A component should have a single reason to change, which means aligning it with one source of change. This is about deciding what assemblies or libraries your system should have so work does not get intermingled across teams.

The takeaway

The main idea is the dependency rule, not a trendy word like SOLID. That’s how i see it today. It took me years to get here, and I'm open to change my mind.

In case you find the above interesting, i have developed a complete course with an ordering service use case. It covers folder setup, core domain logic (anemic vs. rich), use case orchestration, and gateways implementing core interfaces.