Why SOLID sucks
No it doesn't, but now that I have your attention (sorry for the clickbait), let me explain why every influencer talks about SOLID and, yet, we keep seeing crappy code all over the place.
Note: I'm not going through what SOLID means. There are plenty of material online.
The biggest problem with SOLID is that it is sold as something that you apply in the implementation phase (classes, interfaces, etc.) when, in reality, they are DESIGN principles.
Things get mixed up because almost always the given examples involve things like shapes, mammals, etc., which are common entities with semantics that pretty much everybody knows about (what they are, how they behave, and how they relate to each other).
However, when it's time to implement real world software, engineers are left alone with a bunch of entities they know little or nothing about (except for what is described in the user stories) and, worse, they have no time to have any kind of "philosophical" discussions because the sprint clock is ticking.
So, yeah, it's easy for an engineer to say that a triangle is a shape or that a whale is a mammal. But what about a discount? What about a refund? What about a credit? And an adjustment? Are they related somehow? Do they have any intrinsic commonality? Or the apparent commonality visible in the user stories apply just to that specific scenario?
Also, how they relate to accounts? Talking about accounts, what is a, individual account, joint account, a business account, a small business account, a kids account, etc.?
You see how deep it can go.
All those questions must be asked and answered BEFORE a single line of code is even written.
But unfortunately, the design phase is probably one of the most neglected phases in the software development life cycle. Even when done, it does not involve discussions about the semantics of every entity that is part of the implementation.
Engineers with long experience in the business domain usually are capable to apply those principles but not necessarily because they are great engineers. it's because they have the required knowledge about the entities and their semantics (granted, some engineers have the knowledge but not the technical skills to apply, but this is another conversation). And they have been applying SOLID principles for ages - there is nothing new about it.
However, those engineers who are not familiar with the domain (juniors, contractors, etc.), they need the time to discuss the entities and have a clear understanding of their semantics. Only then, they will be able to capture ontological hierarchies, establish relationships and apply the principles when designing the entities; and the implementation should come naturally.