O primeiro dia da OLW 3ª edição começou sem código na tela. Antes de tocar em Docker ou terminal, os instrutores desenharam no papel toda a modelagem de dados de um checkout de e-commerce integrado ao Mercado Pago — porque, como disseram ao vivo, "uma alteração no papel leva 10 segundos; a mesma alteração no código pronto leva semanas". Só depois de validar esse desenho é que a live migrou para o terminal: clonar o repo, subir o ambiente com Sail, resolver os erros clássicos de instalação e transformar o modelo em migrations, models, enums e factories reais.
Destaques
- Modelagem em papel primeiro: entidades usuário → endereços (1:N) → pedido → produtos, com pedido funcionando como "carrinho" (user_id e session_id nullable para suportar carrinho sem login).
- Produto quebrado em SKU + atributos (cor, tamanho) num relacionamento N:N via tabela pivô, pensando em controle de estoque futuro.
- Cópia deliberada de dados sensíveis a mudança: preço do SKU copiado para
order_sku(o preço do pedido não pode variar com o tempo) e endereço copiado inteiro na tabela de shipping (evita entregar no lugar errado se o usuário mudar o endereço depois do pedido pago). - Setup do projeto ao vivo com Sail:
cp .env.example .env,./vendor/bin/sail up -d, e resolução na hora de erros reais — APP_KEY ausente (php artisan key:generate), Vite não encontrado (npm install+npm run dev), conexão de banco recusada (apontarDB_HOSTpara o container certo) e tabela não encontrada (php artisan migrate). - Uso de
php artisan make:model Nome -mpara gerar model e migration juntos, criação de todas as migrations em lote ("esteira de produção") e só depois população campo a campo. foreignId(...)->constrained()explicado na prática: cria a FK e o índice no banco, não só a coluna — melhora performance de JOIN.- Enum nativo do PHP 8 usado para status (checkout steps, order status) com métodos custom (
getName(),getStyles()) ecasts()no model para inserir/ler automaticamente o enum como inteiro no banco; discussão clara sobre quando usar Enum (regra estável, exige deploy pra mudar) vs. tabela (regra de negócio alterada por quem não é dev). - Relacionamento
belongsToManycom pivot customizada (classePivot, nãoModel) paraorder_sku, incluindo->using()e cast de coluna JSON para guardar snapshot do produto no momento da venda. - Factories e seeders organizados em classes separadas (um seeder por entidade, chamados via
DatabaseSeeder), com uso dehas('address')no seeder de usuário para já criar relacionamentos automaticamente.
Profundidade tecnica
A live foi além do "CRUD básico": tratou de decisões que só aparecem em e-commerce real, como por que copiar preço e endereço em vez de só referenciar (snapshot de dados no momento da transação), diferença entre pivot table comum e classe Pivot dedicada, e o motivo prático de sempre usar ID auto-incremento em vez de chave composta. Também mostrou o fluxo de versionamento de banco via migrations (batches, rollback) e reforçou a leitura de mensagens de erro como parte do processo de debug — em vez de pular direto pra pedir ajuda no grupo, a orientação foi sempre ler o que o Laravel já está dizendo na tela.
Faça parte do Clã
Se você curtiu ver modelagem de e-commerce sendo pensada e traduzida em código Laravel ao vivo, isso é só uma amostra do que rola dentro do Clã Beer and Code — encontros técnicos como esse, mentoria direta com quem constrói esse tipo de projeto no dia a dia, e uma comunidade que discute arquitetura, boas práticas e código de verdade. Entre para o Clã Beer and Code e tenha acesso a esse conteúdo e muito mais.
Engenharia de IA virou profissão, e se aprende construindo, não assistindo. O Clã Beer and Code é o ambiente onde isso acontece ao vivo, toda semana: RAG, agentes, observabilidade e LLMOps em projetos reais, ao lado de quem já está em produção. É pago, é assinatura, e é exatamente o ambiente que estes encontros dão uma amostra.
Entrar no Clã