SOLID: Change Code Without a Chain Reaction
SOLID is five design principles from Robert C. Martin that help design the boundaries of classes and modules. Its goal isn't to increase the number of interfaces. The goal is that changing one detail doesn't force rewriting everything around it - that is, to remove the chain reaction of edits.
Briefly, the five letters answer five questions. S - a part has one reason to change. O - behavior is extended without rewriting what exists. L - an implementation can be replaced with no surprises for the caller. I - interfaces are small, the client doesn't depend on the extra. D - code depends on agreements, not on concrete details. All of these are ways to keep one change from spreading across the system.
SOLID is applied by need, not by schedule. A small project rarely needs the full architectural set from day one. Use a specific SOLID principle when it removes an observable problem, not "to be correct."
What is the goal of SOLID?
Now let's put SoC and SOLID together on our order - and see where boundaries are justified and where they'd be excessive.