Uma demanda raramente chega como um problema limpo. Ela costuma misturar objetivo, solução sugerida, uma tela imaginada e várias exceções ainda não ditas. Se começo direto pelo banco ou pelo endpoint, posso implementar com eficiência uma interpretação errada.
Modelar é escolher o que precisa existir no software para apoiar uma decisão. O diagrama, a classe e a tabela vêm depois. Parece uma diferença pequena, mas muda bastante as perguntas feitas no início.
Procure o comportamento
Substantivos aparecem fácil: usuário, pedido, consulta. O trabalho interessante está nos verbos. Quem agenda? Quando pode cancelar? O que muda após a aprovação? E se duas ações ocorrerem juntas?
Gosto de testar a conversa com casos incômodos: duplicidade, atraso, falta de permissão, dado incompleto. É aí que regras antes “óbvias” começam a ganhar contorno.
Todo modelo deixa algo de fora
Um modelo não é uma cópia da realidade. É um recorte útil. A mesma pessoa pode ser paciente no contexto clínico, destinatária em comunicação e responsável financeira em cobrança. Colocar todos esses papéis em uma entidade central só transfere a complexidade para campos opcionais.
- Objetivo: o resultado que importa para alguém.
- Estado: o que precisamos saber para tomar uma decisão.
- Transição: uma mudança permitida e suas condições.
- Fronteira: onde aquele conjunto de conceitos faz sentido.
Do exemplo para a implementação
Transformo cenários em casos de uso e testes. A aplicação coordena; o domínio toma decisões; adaptadores conversam com HTTP, banco ou serviços externos. Essa separação não precisa virar dezenas de pastas. Ela só precisa impedir que a regra dependa do formato de uma requisição.
Persistência também é escolha. Às vezes objeto e tabela podem ser quase iguais. Quando isso começa a deformar o modelo, um mapper simples é mais honesto do que fingir que não existe diferença.
Modelos aprendem com o produto
Construindo a ANIMAPS, percebi que algumas capacidades que pareciam próximas mudavam por razões bem diferentes. Na KasbHealth, regras clínicas deixam isso ainda mais claro: inferir o domínio a partir da tela é um atalho perigoso.
Nenhum desses projetos ofereceu um molde universal. Eles reforçaram um hábito: ouvir os termos, procurar decisões e voltar ao modelo quando uma nova informação derruba a primeira hipótese.
A primeira modelagem não precisa estar certa para sempre. Precisa ser clara o bastante para podermos corrigi-la.
Como saber se o recorte ajuda
Observo onde uma regra nova cabe. Se ela exige condicionais em cinco módulos, talvez a fronteira esteja errada. Campos opcionais demais, serviços que só repassam dados e testes presos à implementação também são sinais úteis.
Um bom modelo reduz a quantidade de contexto necessária para uma mudança. Quando passa a exigir mais tradução do que poupa, é hora de simplificar.
Conclusão
Modelar software é sustentar uma conversa entre realidade e código. Perguntamos, fazemos um recorte, implementamos e confrontamos o resultado com novos casos. A qualidade não está em produzir a abstração mais elegante, mas em manter as decisões do sistema compreensíveis e revisáveis.