Whether to procreate intermediaries, or make one bold?

Question

Laravel

In one of my applications, there are too many intermediaries, but in each of them essentially the same thing happens, the $request variable is processed. It also happened that in each of them, different models are called for some checks, but the logic is the same everywhere. I don’t really imagine Laravel’s magic in terms of optimizing dependencies on this yet, and the question is: From the point of view of performance in this case in terms of memory usage, is it better to have an intermediary for each model, or you can make one intermediary where all models will be declared, or is it better to do one intermediary and not use models in it, but use only QueryBuilder? Or is it all millimetrics in terms of resources and it is more important to adhere to the principles of solid and spawn a bunch of intermediaries for each model and introduce a dependency into all these intermediaries to process similar logic?
I'm more than sure that my question is stupid, but a lot of dependencies, inheritance, etc. are really annoying me. I want to take and pile the code into one file! And it seems that everyone will be better for it ...

Answer 1

My own answer arose spontaneously as a product of communication with colleagues (thanks @kliss) and meditation. There are no life hacks on how to do bad things. Bad things can always be done well. Now I will save half an hour on putting all the logic into one middleware by creating an extensive "if else" network and burying my laziness in one file. But when the time comes to return the "technical debt" at the time of scaling, I will definitely remember those 1.5 parrots that I regretted for allocating memory (although I still don’t know if unclaimed model declarations in Laravel eat memory with impunity, how does it then mappit and optimizes for the route for me so far magic). And it will most likely be, first of all, suddenly, and secondly, untimely. And this applies to everything related to the architecture of logic.