MVC não está morto, apesar do que sugerem alguns debates sobre arquitetura. Depois de anos alternando entre MVC puro, DDD e Arquitetura Hexagonal, minha conclusão é pragmática: MVC ainda é a escolha certa para boa parte dos projetos que entrego — só não para todos.
Quando o MVC resolve bem
Para sites institucionais, painéis administrativos simples e CRUDs sem regra de negócio complexa — boa parte do que a Inova Factory entrega — o MVC do Laravel puro é suficiente e mais rápido de entregar. Adicionar camadas de domínio nesses casos é custo sem retorno: ninguém vai sentir falta de uma Arquitetura Hexagonal em um site institucional que só lista serviços e recebe formulário de contato.
Um exemplo concreto: um site institucional com página "Sobre", "Serviços" e um formulário de contato não tem regra de negócio nenhuma que justifique separar domínio de infraestrutura. O Controller recebe a requisição, valida os dados e envia o e-mail. Três camadas para isso seriam apenas indireção sem propósito — e indireção sem propósito é o oposto de Clean Code, não uma versão mais sofisticada dele.
Quando eu saio do MVC puro
A régua que uso é a complexidade da regra de negócio, não o tamanho do projeto. Quando existe lógica de domínio que muda com frequência, que precisa ser testada isoladamente ou que vai crescer — como no Simulado Solidário — aí sim vale sair do Controller-Model direto e organizar em camadas. Escolher a arquitetura certa é, antes de tudo, saber reconhecer qual problema você realmente tem.
Um critério prático para decidir
Pergunto três coisas antes de escolher: essa regra vai mudar nos próximos meses? Ela precisa ser testada sem depender de banco de dados? Mais de uma pessoa vai mexer nesse código? Duas respostas "sim" já são sinal de que vale investir em camadas — o que eu detalho em Arquitetura Hexagonal na prática e em Por que escolho DDD mesmo em projetos pequenos.
