Quando um projeto começa pela tela, a equipe costuma desenhar cedo demais uma resposta para uma pergunta que ainda não entendeu. O software pode ficar bonito e ainda assim obrigar a operação a contorná-lo todos os dias.
Antes do código, existe um fluxo: pessoas tomam decisões, informação muda de estado, exceções aparecem e alguém precisa responder pelo resultado. É ali que a arquitetura começa.
A interface é a última camada
Uma tela não é o processo. Ela é uma representação temporária do que o processo precisa permitir. Quando tratamos o layout como fonte de verdade, regras importantes acabam espalhadas em cliques, permissões implícitas e automações que ninguém consegue explicar.
Eu prefiro começar nomeando estados, atores e transições. O que entra? Quem pode mudar? O que precisa ser registrado? O que acontece quando uma dependência falha? As respostas viram contratos antes de virarem componentes.
Mapear o fluxo real
O processo descrito no documento raramente é o mesmo que acontece numa terça-feira difícil. Por isso a descoberta precisa acompanhar casos reais, inclusive atalhos e planilhas paralelas. Eles não são apenas dívida: são evidência de uma necessidade que o sistema atual não cobre.
O mapa útil não tenta registrar cada gesto. Ele destaca decisões irreversíveis, pontos de espera, dependências externas e lugares onde contexto se perde. Isso orienta melhor a modelagem do que uma lista de funcionalidades.
Arquitetura como acordo operacional
Filas, eventos, APIs e bancos são escolhas técnicas. A razão de cada escolha precisa ser operacional: tolerar atraso, preservar rastreabilidade, reduzir acoplamento ou proteger um dado. Quando a justificativa não cabe numa frase clara, a complexidade provavelmente chegou cedo.
O bom sistema não elimina toda exceção. Ele torna a exceção visível, limita o dano e oferece uma forma segura de retomar o fluxo. Esse é o tipo de qualidade que continua existindo quando a tecnologia muda.