Interessante, eu vejo o Controller onde o local que você usa as regras de negócio que estão no Model, por isso você pode usar o mesmo model em vários lugares e com isso carregar consigo as mesmas regras de negócio. Então as "regras" que estão no Controller são sobre como usar os Models, em qual sequência e quando.
Acha que faz sentido?
Achei realmente interessante. Pra mim faz sentido também, embora temos o conceito original de que toda regra de negócio fique estritamente no Controller.
Poderia dar um exemplo de como seria isso ?
Segundo o livro Patterns of Enterprise Application Architecture, o controller do MVC é responsável pela lógica de apresentação da view. No mundo ideal, ele serviria como uma implementação do Strategy Pattern pra view. O livro chega a mencionar que poderiam existir 2 controllers pra uma mesma view, um para quando ela for editável e outro para quando não for. Mas, na prática, geralmente implementam-se apenas 1 controller por view.
Mas e as regras de negócio? Bom, quando a gente fala de MVC, acredito que a confusão está justamente no papel da model, que segundo o livro, é de conter as regras de negócio E de acesso a banco de dados, por exemplo. Digo que a confusão vem daí, pois quando nos aprofundamos em conseitos como SOLID, percebemos que essas duas responsabilidades são completamente distintas e acabamos levando as regras de negócio para o controller.
Eu acredito que muitos sistemas tenham adotado uma "camada de serviço" (coloco entre aspas pois não é o Service Layer Pattern) por conta dessa confusão. Nessa camada estão os objetos que "servem" as regras de negócio pro controller e utilizam as models como dados (e acesso à base de dados).
No mundo ideal (na minha visão), as views são templates, as models são as classes com regras de negócio (implementação do Domain Model) e os controllers são os instanciadores de models e views. Mas aí a gente adiciona mais algumas camadas no modelo a depender do projeto, como a camada de acesso à base de dados (separada das models).
Vocês acham que faz sentido essa minha visão de "mundo ideal"?
Faz total sentido! Até por conta do reuso do model, onde um mesmo Model pode existir em vários lugares, enquanto não vejo isto se repetindo com o Controller. Vejo que o Controller deve usar o Model e injetar isso na View, seja o que esta "View" for.
Por exemplo, no TabNews, o model Content responsável pelso conteúdos é usado tanto no Controller da API, quanto na geração das páginas estáticas (dentro do getStaticProps, e que seria análogo a um Controller da View das páginas).