Onde deve ficar minha regra de negocio no padrão MVC?

Visão tradicional do MVC: o Model representa o estado: regra de negócio + dados, ou comportamento + dados.

https://martinfowler.com/eaaCatalog/domainModel.html

Se pensar que Model é "manipulação de dados", então a conclusão é embutir a lógica de negócio nessa camada.

• Model e subclasses tendem a ficar longos
• Model agora tem várias responsabilidades
• Model restrito a um Domínio
• Model tende a ficar restrito a uma aplicação (polêmico)
• Model notifica a View ou Controller da mudança de estado
• Model fica superutilizado: responde, manipula, notifica, etc.

Visão alternativa do MVC: o Model é separado das regras de negócio.

No diagrama acima, o Model agora é apenas aquele tambor/cilindro à direita do diagrama.

Se pensar que Model é "a fonte de dados", ou seja, uma implementação passiva do Model, então a conclusão é criar uma camada adicional chamada Domínio (ou qq nome que faça sentido pra você) com vários componentes/módulos dentro e que armazena as regras de negócio. MVCD poderia ser o nome.

• Model fica enxuto
• Model tem a responsabilidade única de acessar uma fonte de dados
• Model fica subutilizado, só responde
• Domain fica cheio de namespaces, pastas, componentes
• Domain cuida das alterações de estado
• Model só responde a comandos do Controller, ou da View (nesse caso, Presenter)
• Domain fica superutilizado: manipula, notifica, etc.

Dá uma lida também nos padrões de projeto: Observer (Pub/Sub), Strategy e Composite. Factory e Decorator também podem ajudar a depender do framework usado.

Perfeito,muito obrigado,ajudou bastante