I more or less agree, the main issue with your "Model" is that it doesn't separate Data from Service (or Manager or Database or whatever your data-management la

I more or less agree, the main issue with your "Model" is that it doesn't separate Data from Service (or Manager or Database or whatever your data-management layer looks like). A lot of "MVC" has Model as a dumb Data-Model, and data is passed around between the service/manager/db and controller a lot. It's very rare (that I've seen) that you truly have so-called Model code talking directly to the controllers. There is also the question of data-flow in larger "MVC" containers - where either numerous "views" must co-operate (e.g. in the case of complex nested lists), and must choose some combination of view-to-view communication (often in the case of layout-intense code), or view-to-controller-to-controller-to-view communication, or in some cases view-to-controller-to-service-model-to-controller-to-view communication. Often the pattern applied to de-congest such a system is a service-oriented or micoservice, or event pattern, although all of these tend to introduce overhead and hence in-efficiencies compared to tightly coupled e.g. view-to-view communication, or tightly coupled controller to controller communication. I suppose what I am arguing is that Model is a bit of a misnomer - you must always operate upon data, all code is simply transforming that data and the best way to transform that data is usually context specific to some combination of business and practicality needs... so the "Model" unless strictly defined as "the raw data structures" tends to somewhat overlap and envelope the other roles.