Colocar regra de negócio no controller é o caminho mais rápido para um código impossível de testar. Veja como a divisão Service/Controller muda o jogo.
O sintoma do controller gordo
Controllers com centenas de linhas são um anti-padrão fácil de identificar mas difícil de evitar sob pressão. O caminho de menor resistência é colocar a lógica onde o contexto já está — o controller — e isso cria dívida técnica rapidamente.
A regra simples
Um controller deve fazer exatamente três coisas: extrair input da request, chamar um ou mais métodos do Service, e construir a response. Nenhuma query direta ao banco, nenhuma regra de negócio, nenhuma validação de domínio.
Services como orquestradores
O Service é o lugar certo para: validação de domínio (não de formato), consultas ao banco, lógica de negócio, transações, e disparo de notificações. Ele não conhece HTTP — recebe dados primitivos, retorna dados primitivos ou lança exceções.
Se você consegue testar o Service sem fazer nenhuma requisição HTTP, a divisão está correta. Controllers são difíceis de testar; Services são triviais.
Tratamento de erros
Services lançam exceções de domínio (AppException, ValidationException). O ErrorHandler centralizado as captura e transforma em responses HTTP apropriadas. Isso elimina try/catch repetitivos nos controllers.
Publicado em
Arquitetura de SoftwareExplorar por tema