Modelar software exige conhecer o negócio antes do padrão

A dificuldade da modelagem de software está menos em escolher o padrão correto e mais em representar um negócio que o programador ainda não entende. Fabio Akita sustenta essa ideia ao deslocar a discussão de livros e arquiteturas para exemplos concretos: usuário, endereço, preço, estoque, pagamento, imposto, logística. O ponto é direto. Uma classe ou tabela aparentemente simples costuma esconder regras de domínio que só aparecem quando o sistema encontra a operação real.

O exemplo do e-commerce mostra o mecanismo. Um iniciante tende a imaginar usuário como uma pessoa com nome, e-mail e endereço. Mas o cadastro pode envolver autenticação, redefinição de senha, auditoria, endereço de cobrança, endereço de entrega, perfis de funcionário, fornecedor ou consumidor, pontos de fidelidade e exigências legais. O mesmo ocorre com produto: não basta cadastrar um carro ou uma camiseta. Em varejo, o item vendável pode ser um SKU específico, como um modelo, ano, versão e cor de veículo, ou uma camiseta de uma estampa em determinado tamanho. A modelagem muda porque o negócio exige distinções que a experiência cotidiana não revela.

Daí a ressalva sobre livros como DDD, design patterns e arquitetura. Akita não os descarta; ele os coloca no tempo certo. Sem quilometragem em código, legado e problemas reais, a leitura vira regra decorada. O caso do overbooking no exemplo de entregas atribuído a Eric Evans ilustra isso: permitir 10% de carga extra pode ser apenas uma cláusula escondida num método, até alguém perceber que aquilo é uma política de negócio e merece uma forma explícita no modelo. O padrão ajuda a nomear e separar a decisão, mas não descobre sozinho que a regra existe.

A consequência prática é desconfortável para quem procura um roteiro completo. Tutoriais e livros reduzem o problema porque precisam caber em poucas centenas de páginas; plataformas reais acumulam anos de mudanças, integrações, impostos, auditorias, aquisições e prioridades novas. Por isso, trabalhar em sistemas existentes, fuçar projetos abertos, receber feedback de gente mais experiente e lidar com software ruim não são etapas inferiores à teoria. São as condições para enxergar o domínio que depois será modelado.

Assistir ao episódio original

Referências encontradas

Livros

• Código Limpo: Habilidades Práticas do Agile Software, de Robert C. Martin — Ver livro na Amazon
• Domain-Driven Design: Atacando as Complexidades no Coração do Software, de Eric Evans — Ver livro na Amazon
• Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos, de Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides — Ver livro na Amazon
• Padrões de Arquitetura de Aplicações Corporativas, de Martin Fowler — Ver livro na Amazon
• A Guerra dos Tronos : as Crônicas de Gelo e Fogo, Volume 1, de George R. R. Martin — Ver livro na Amazon

Séries

• ワンピース — Ver no TMDB
• ナルト — Ver no TMDB
• Game Of Thrones — Ver no TMDB

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.