Clean Architecture em PHP: Vale a Pena em Projetos Laravel?
Clean Architecture é um dos tópicos mais debatidos na comunidade Laravel — e também um dos mais mal aplicados. Vou dar minha visão honesta depois de ver projetos de todos os tamanhos.
O que é Clean Architecture (de verdade)
Clean Architecture, popularizada pelo Uncle Bob, define camadas com dependências sempre apontando para o centro:
- Entities: regras de negócio puras, sem dependências externas
- Use Cases: orquestração da lógica de aplicação
- Interface Adapters: controllers, presenters, gateways
- Frameworks & Drivers: Laravel, banco de dados, HTTP
Quando Faz Sentido em Laravel
A resposta honesta: raramente do jeito "puro".
Laravel é um framework que abraça o "Active Record" (Eloquent) e convenções over configuration. Forçar Clean Architecture completa significa lutar contra o framework em vez de trabalhar com ele.
O que funciona bem é um meio-termo pragmático:
- Use Services para orquestrar lógica de negócio complexa
- Use Actions (padrão do Laravel Jetstream) para casos de uso simples
- Mantenha os Models com lógica de domínio simples (scopes, accessors, mutators)
- Reserve a estrutura completa de Use Cases + Repositories para domínios realmente complexos
A Regra Prática
Se você consegue explicar a regra de negócio em um parágrafo, um Service resolve. Se a lógica tem múltiplos atores, invariantes complexas e casos de borda, aí sim vale a complexidade de camadas adicionais.
Over-engineering mata produtividade tanto quanto código espaguete. Encontre o equilíbrio.
Posts relacionados
Multi-tenancy em Laravel: Single DB vs Schema Separado vs Banco Separado
Uma análise prática das três abordagens de multi-tenancy no Laravel, com os trade-offs de...
RAG na Prática: Construindo um Chatbot que Realmente Sabe o que Fala
Tutorial completo de RAG (Retrieval-Augmented Generation) com Laravel, pgvector e OpenAI —...