Workshop: Arquitetura e Padrões de Projeto no Laravel

O clima foi de bate-papo técnico entre quem já bateu a cabeça em produção: Danilo e Virgão trocaram cases reais de empresas grandes (6 mil e 10 mil funcionários) e startups, contrastando arquitetura "correta no papel" com o que de fato funciona no dia a dia de um time Laravel. O foco do encontro foi desmistificar hype de arquitetura — repository pattern, DDD, hexagonal, microsserviços — mostrando onde cada um se paga e onde só atrapalha a entrega.

Destaques

• Definição direta de arquitetura: "é a forma como você organiza pastas e arquivos" e como isso reflete na forma de testar e evoluir o projeto — não é dogma, é ferramenta.
• Debate sobre repository pattern: os dois palestrantes contaram que já tentaram usar (mais de uma vez) e sentiram queda de produtividade; a conclusão foi que trocar de ORM raramente acontece na prática, então isolar essa camada geralmente é custo sem retorno no Laravel.
• DTO no Laravel foi chamado de desnecessário na maioria dos casos — conceito que "vem do Java" e que no ecossistema Laravel, com Eloquent fazendo o papel de transporte de dados, tende a adicionar complexidade sem ganho real.
• Camada de serviço (service layer) apresentada como a peça central da arquitetura recomendada: lógica de negócio isolada do controller, reaproveitável tanto via HTTP (controller) quanto via console/Artisan — bastando cuidar do payload de entrada e do formato de saída (array, model, etc.).
• Explicação do service container do Laravel como o conceito mais importante para entender injeção de dependência no framework, e como facades são só uma forma de acessar essas classes de forma estática.
• Padrões de projeto nativos do Laravel na prática: Observer (equivalente aos eventos/triggers do framework) e Strategy (ex.: variar forma de pagamento — cartão, PayPal, boleto — mantendo o mesmo contrato).
• Alerta forte sobre má interpretação do princípio de responsabilidade única do SOLID: caso real de um dev que fragmentou uma classe em 30 métodos de uma linha achando que estava seguindo o princípio "by the book" — e só deixou o código pior.
• Parte prática: criação de um projeto Laravel do zero com Breeze, estruturando MVC + service layer como ponto de partida recomendado para a maioria dos projetos.

Profundidade tecnica

A discussão foi além do "como fazer" e entrou fundo no "quando fazer": os palestrantes trataram microsserviços e DDD/hexagonal como armadilhas comuns de CTO júnior — soluções para gargalo que só fazem sentido quando o monolito já demonstrou não dar conta, e que sem esse gatilho normalmente apenas aumentam custo de observabilidade (citado o caso de Datadog explodindo custo com centenas de microsserviços) e complexidade de manutenção sem benefício correspondente.

No nível de código, o encontro deixou claro que SOLID, Clean Code e Clean Architecture funcionam como "farol", não como regra rígida — a armadilha mais citada foi aplicar princípios ao pé da letra sem entender a intenção por trás deles. A recomendação prática e repetida foi: comece simples (MVC + service layer), teste a aplicação, mantenha padrão de escrita com Pint e análise estática, e só evolua a arquitetura conforme o negócio evoluir de verdade — não antecipando complexidade que talvez nunca chegue.

Faça parte do Clã

Se você curtiu esse nível de discussão prática sobre arquitetura Laravel — sem papo de bala de prata e com quem já bateu a cabeça em produção — o Clã Beer and Code é o próximo passo. Lá você tem acesso a encontros como esse, mentoria técnica direta e uma comunidade de devs Laravel que troca experiência real de arquitetura, código e carreira todo santo dia.