As you know, I am a fan and practitioner of CQRS.. I believe that it is falsely considered as complicated. In my opinion, it can help even with the classic CRUD approach. For example, if we know that a given method is only used to return data, we can optimise it. Even in the ORM (e.g. Entity Framework), knowing that we won’t modify the data, by disabling changes tracking, we can make queries run faster.
Minor optimisations are fun, but these strategic changes are worth more. I often refer to “Clean Architecture” as “Onion Architecture”. Not only because of the layers’ abundance. Also, because of the specific smell that hangs around it. In Onion Architecture, we divide our code into horizontal layers: API layer, application layer, business layer, data layer, and so on and so forth. Matrioshka called a “decent, enterprise” architecture. Why am I clinging to the scent?
All of that conveys into cognitive load and directly to software development and implementation costs. Moreover, it increases the risk of change. If we are going to change the generic repository, we risk breaking everything by having a bad if. This often leads to abandonment and avoidance of changes, or worse, workarounds with hacks.