Middleware é um dos recursos mais poderosos do Laravel e um dos mais fáceis de usar em excesso. A pergunta que faço antes de criar um novo middleware é simples: essa lógica precisa rodar antes de toda requisição chegar no Controller, ou é regra de negócio disfarçada de infraestrutura?
Onde middleware é a escolha certa
Autenticação, verificação de permissão de rota, log de requisição, rate limiting — tudo que é transversal a múltiplas rotas e não muda dependendo da regra de negócio específica daquela rota. É o mesmo raciocínio de centralizar decisão em um único lugar que aplico em autenticação e permissões: uma verificação, um lugar, sem duplicar em cada Controller.
Onde middleware vira armadilha
Já vi middleware carregando regra de negócio específica de uma única rota, tornando o fluxo difícil de seguir — quem lê o Controller não imagina que boa parte da lógica está escondida em uma camada anterior, invisível no arquivo que está olhando. Regra de negócio pertence ao domínio, não ao pipeline de requisição.
Uma linguagem que reforça essa disciplina
Curiosamente, foi estudando outras linguagens — como Java, com sua separação mais rígida entre camadas — que reforcei esse instinto de não deixar regra de negócio vazar para onde ela não pertence.
