[jeremydeanlakey]

The central idea around cognitive load is very good, central to writing good code.

But it's deeply mistaken to oppose smaller (or more correctly: simpler) classes/functions and layered architecture.

Layered architecture and simple (mostly small) classes and methods are critical to light cognitive load.

e.g. You should not be handling database functionality in your service classes, nor should you be doing business logic in your controllers. These different kinds of logic are very different, require different kinds of knowledge. Combining them _increases_ cognitive load, not decreases.

It's not mainly about swapping out dependencies (although this is an important benefit), it's about doing one thing at a time.

[jillesvangurp]

There are some nice studies on correlations between metrics (cohesiveness, coupling, complexity, levels of indirection, etc.) and maintainability. Basically anything that scores poorly is inherently hard to understand because it induces a high cognitive load.

The reason what you outline is bad is because they each impact these metrics. Bypassing layers creates a more tight coupling: you are basically putting code in the wrong place. This also makes the code less coherent. The two go hand in hand. And then you end up doing complex things like reaching deep into layers (which violates Demeter's law).

Anyway, MVC style architectures have always had the problem that they invite people to mix viewer and controller code and logic. And once your business logic mixes with your rendering logic, your code is well on its way of becoming yet another UI project that fell into the trap of tight coupling, low cohesiveness, and high complexity.

[jeremydeanlakey]

To make this more concrete:

If your service layer method requires data to be saved and the results to be sorted, you want to call a data layer method that saves it and a library method that sorts it. You do not want any of that saving or sorting functionality in your service method.

Combining different layers and different tasks so that your module is "deep" rather than "shallow" will make your code much higher cognitive load and create a lot of bugs.