Por que arquitetura importa? Porque software só resolve o problema que alguém entendeu.

O primeiro entregável de um projeto é uma boa pergunta.

Começo conversando com quem conhece o negócio por dentro: quem decide, quem vende, quem atende e quem opera. Cada um enxerga o problema de um ângulo, e é comum que as versões não batam. Essas diferenças costumam apontar exatamente onde o software vai precisar de mais cuidado.

Nessa fase anoto as palavras que cada pessoa usa, os casos que fogem da regra e os momentos em que alguém diz “depende”. É ali que mora a complexidade real, aquela que nenhum formulário de requisitos captura.

Também pergunto o que acontece se o projeto não for feito. A resposta mostra o tamanho do problema e ajuda a definir quanto vale a pena investir em cada parte.

Para o seu médico, você é paciente. Para o financeiro, você é cliente.

Seria estranho ouvir o médico chamar você de cliente. No consultório, você é um paciente: importam os sintomas, o histórico, as alergias e o que foi receitado. Na recepção e no financeiro do mesmo hospital, você é um cliente: importam o documento, o endereço, o convênio e a forma de pagamento.

É a mesma pessoa, mas cada área do negócio enxerga uma versão diferente dela, com dados diferentes. E é bom que seja assim. Você não quer o seu médico olhando o número do seu cartão de crédito, nem alguém do financeiro lendo o seu diagnóstico.

Todo negócio tem os seus “pacientes” e “clientes”. Um sistema que junta tudo num único cadastro de “pessoa” mistura o que deveria estar separado: fica mais arriscado, mais difícil de proteger e mais difícil de mudar.

Por isso desenho contextos delimitados: partes do sistema com fronteira clara, vocabulário próprio e dados próprios. Entre elas, defino com um mapa de contextos o que atravessa cada fronteira, e só isso. Cada parte guarda apenas o que precisa saber, a proteção de dados deixa de ser remendo e passa a fazer parte do desenho, e cada área pode evoluir sem arrastar as outras.

Cada regra do negócio precisa de um lugar no código e de alguém que a proteja.

Dentro de cada contexto, desenho as peças que guardam as regras. O DDD dá nome a quatro delas.

Entidade é o que tem identidade própria. O paciente troca de endereço e de convênio e continua sendo o mesmo paciente.

Objeto de valor é uma descrição que não muda depois de criada. Se a rua ou o número de um endereço mudam, já é outro endereço. O seu endereço não muda. Quem muda é você.

Agregado reúne o que precisa mudar junto e protege as regras que nunca podem ser quebradas. O limite dele é o de uma transação: tudo o que está dentro é salvo de uma vez, ou nada é salvo. Toda alteração passa pela raiz do agregado, que recusa qualquer pedido capaz de deixar o negócio num estado inválido.

Evento de domínio é o aviso de que algo relevante aconteceu, escrito no passado. É assim que o financeiro descobre que a consulta terminou sem abrir o prontuário.

Coloco o negócio inteiro numa parede, em ordem cronológica.

A técnica se chama Event Storming. Reunimos as pessoas certas e escrevemos, em notas adesivas, tudo o que acontece no negócio, sempre no passado: pedido confirmado, pagamento recusado, entrega reagendada. Depois organizamos esses eventos numa linha do tempo e perguntamos o que dispara cada um, quem é responsável e quais regras se aplicam.

Em poucas horas aparece um retrato do processo que ninguém tinha visto inteiro. Os pontos de dúvida ou de conflito ganham uma nota de outra cor. São esses pontos que viram as primeiras conversas difíceis e, quase sempre, as decisões mais importantes do projeto.

Quando o processo é mais narrativo, uso Domain Storytelling: alguém do time conta como o trabalho acontece e eu desenho a história com atores, objetos e atividades, até que todos concordem que é aquilo mesmo.

Com o mapa na mão, a pergunta passa a ser onde investir.

Divido o negócio em subdomínios e classifico cada um. O núcleo é o que diferencia a sua empresa da concorrência e merece o melhor do orçamento e da atenção. Os subdomínios de suporte são necessários e específicos do seu negócio, mas não são o motivo pelo qual os clientes escolhem você. Os genéricos são problemas que todo mundo tem, como login, pagamento e envio de e-mail.

Essa classificação muda o orçamento do projeto. Problema genérico se resolve com uma ferramenta pronta e confiável. Suporte pede uma solução simples e bem feita. Código sob medida e cuidado de artesão ficam com o núcleo.

Só depois de entender o negócio é que escolho a tecnologia.

Defino com você os atributos de qualidade que importam para o produto: quantas pessoas ao mesmo tempo, quanto tempo pode ficar fora do ar, quanto pode custar por mês, quão rápido precisa responder. Cada atributo vira um cenário concreto, e é contra esses cenários que comparo as alternativas.

Em um e-commerce, disponibilidade é faturamento: na Black Friday, cada minuto fora do ar é venda que vai para o concorrente. O cenário passa a ser “o carrinho e o pagamento continuam funcionando mesmo se as recomendações ou o cálculo de frete caírem”. Em um sistema de agendamento, o que não pode falhar é a consistência: duas pessoas nunca ficam com o mesmo horário. Em um painel interno usado por dez pessoas, o atributo que mais pesa pode ser o custo baixo por mês. Cada produto tem as suas prioridades, e a arquitetura certa é a que atende às prioridades dele.

Separo as decisões fáceis de reverter das difíceis. As primeiras eu tomo rápido. As segundas ganham tempo, protótipo e um registro escrito, o ADR (registro de decisão de arquitetura), com o contexto, as opções avaliadas e o motivo da escolha. Quem chegar ao projeto daqui a dois anos vai entender por que ele é do jeito que é.

O resultado é o blueprint da aplicação: diagramas do panorama geral até os componentes, a estrutura de dados, as integrações e as diretrizes para o produto crescer.

O modelo do negócio vive dentro do código.

Os nomes das classes, das funções e das tabelas são os mesmos que o seu time usa no dia a dia. As regras importantes ficam juntas, protegidas e cobertas por testes escritos na linguagem do negócio. Quando alguém pergunta “o que acontece se o pagamento for recusado?”, a resposta está num lugar só.

E como o negócio muda, o modelo também muda. Depois do lançamento, volto ao mapa sempre que surge uma regra nova ou uma fronteira começa a incomodar. É assim que o produto continua fácil de mudar no segundo ano, e não só no primeiro mês.