Having a big code mass demands some kind of principles to make it manageable. SOLID is one of the more used principle set. Even if it solves problems it appears to create another.
With a vary large codebase, following the SOLID model will drastically increase amount of classes, interfaces and injections.
The first problem is that when I find a object it is not always clear what I can do with this object or event how it is used.
For example if I want to display it, usually I would just type the object and hit dot and a list would show me what I can do with this object. With SOLID there would be another class "somewhere" that handles display styles. How do I find this class? How do I know that it even exists? References sounds like the way to go but it could show over 100 ref and a lot of them may not have anything to do with functionallity of the class.
The second problem(might not be a SOLID problem) is that when using injections it can becomes unclear what code that really is executing during a specific flow. Injections uses interfaces and there can be several classes that implement this interface. So when investigating a specific flow and we encounter a injection we need to dig in to what object that really is injected to know which code that is executed. In a large code this can be vary time consuming to find.
Am I using SOLID the wrong way, or how could I solve the problems?
It's possibile that you will have more code, and for sure each implementation will cost you more because, for example, instead of modifying a specific service you will have to create a new one with interaction of existing infrastructure, and if your modifications will affect also other modular pieces, you have to refactor all other related interfaces without coupling models, services and so on.
Modules/Services must interact but they don't have to be coupled. The more pieces are decoupled the more it costs you (time/effort). The first question is how much are you interested in a real strong SOLID application and which benefit do you take implementing it.
Anyway, when you say:
References sounds like the way to go but it could show over 100 ref and a lot of them may not have anything to do with functionality of the class.
This seems in contrast with the I principle: Interface segregation principle
Because you should have more specific, smaller interfaces instead of fat interfaces. But for sure it is possible that you will have a higher number of nested calls (interacting services through interfaces, for example)
You second problem also:
So when investigating a specific flow and we encounter a injection we need to dig in to what object that really is injected to know which code that is executed
Seems related to problem 1. Because with smaller and more specific interface, and specific flow, you should understand the code involved and it should be clearer than a non SOLID application