Engenharia de Software começa antes do código

Durante boa parte da minha trajetória, eu começava um projeto do jeito que muita gente começa: escolhendo a stack. Linguagem, banco, framework, nuvem. Parecia o ponto de partida natural. Só depois vinham a arquitetura e o código.

Foi trabalhando em projetos de integração entre instituições, com muitas áreas, regras e sistemas envolvidos, que percebi o que faltava nessa sequência. Um sistema pode usar tecnologia moderna, aguentar volume alto e ter uma arquitetura bonita no diagrama e, mesmo assim, representar errado o problema que deveria resolver.

Programar não é o mesmo que fazer engenharia

Programar é escrever instruções que produzem um comportamento. Engenharia de Software é mais amplo: é conceber, construir, verificar, operar e evoluir sistemas de forma sistemática, sabendo o custo, o risco e o impacto de cada escolha.

Uma funcionalidade pode funcionar hoje e ser frágil ao mesmo tempo. Basta que ninguém tenha testado o comportamento, que as decisões não estejam registradas ou que uma mudança pequena quebre algo do outro lado do sistema. A tela mostra o resultado certo; a estrutura por trás já acumula risco.

A diferença está na pergunta. A programação pergunta como implementar. A Engenharia de Software pergunta por que aquilo existe, para quem gera valor, que restrições precisa respeitar, como será verificado, como se comporta quando algo falha e como vai evoluir sem quebrar o resto.

Código que funciona é necessário, mas não suficiente.

O problema mora no domínio, não na API

Pense em uma plataforma que recebe eventos de várias fontes: municípios, empresas, dispositivos. A primeira descrição do projeto costuma ser simples: integrar os dados e deixar disponível para consulta.

Criar uma API que aceita dados é a parte fácil. As perguntas difíceis vieram antes:

Duas mensagens parecidas representam o mesmo evento?
Quando duas fontes divergem, qual prevalece?
Um evento que chegou atrasado ainda tem valor?
Como diferenciar falha de comunicação de ausência real de informação?
Quem pode consultar cada tipo de dado, e quais ações precisam deixar trilha de auditoria?

Nenhuma dessas perguntas pertence ao código. Elas pertencem ao domínio. Sem as respostas, dá para construir uma integração rápida e operacionalmente errada: processa tudo em milissegundos e entrega duplicidades e alertas sem contexto.

Quando o trabalho passou a começar por atores, eventos, estados e regras, as decisões técnicas ficaram mais fáceis de tomar. Identificador idempotente, fila, política de repetição, retenção e controle de acesso deixaram de ser preferência e passaram a ter motivo. (Escrevi mais sobre isso em O custo invisível da falta de integração.)

Toda decisão técnica deveria ter uma origem

Uma decisão técnica ganha qualidade quando dá para rastreá-la até uma necessidade, uma restrição ou um risco real. Alguns exemplos:

Pergunta de negócio	Consequência técnica possível
O mesmo evento pode chegar mais de uma vez?	Identificador idempotente e controle de duplicidade
A resposta precisa ser imediata?	Processamento síncrono ou assíncrono
Quem pode executar a ação?	Autenticação, autorização e políticas de acesso
É preciso reconstruir o que aconteceu?	Trilha de auditoria, correlação e retenção
E se um componente falhar?	Retentativas, fila de exceções e observabilidade

Quando essa ligação não existe, a arquitetura vira uma coleção de gostos pessoais. Entra a tecnologia da moda, entra o padrão que ninguém pediu, e a complexidade acidental cresce. Uma arquitetura madura não é a que tem mais componentes. É a que deixa claro por que cada componente existe.

Um teste rápido antes da próxima sprint

Antes da próxima decisão técnica do seu time, tente responder:

O problema e o resultado esperado estão descritos sem citar tecnologia?
Os atores e suas responsabilidades foram identificados?
Os termos mais importantes significam a mesma coisa para negócio e desenvolvimento?
As regras que nunca podem ser violadas estão escritas?
Exceções, atrasos, duplicidades e indisponibilidades foram discutidos?
Dá para ligar cada decisão técnica importante a uma necessidade ou risco?

Se várias respostas forem “não”, o time ainda está no começo da Engenharia de Software, mesmo que já tenha muito código escrito. Vocabulário compartilhado, aliás, é o ponto de partida do DDD, que tratei em DDD não é (só) para sistemas gigantes.

Para ir além

Esse é o tema do primeiro capítulo do meu livro, Engenharia de Software: Fundamentos e Práticas. Os outros 20 seguem o mesmo caminho, do problema à operação: requisitos, arquitetura, testes, segurança, DevOps e o uso de agentes de IA no desenvolvimento, sempre com casos reais anonimizados, checklist e exercício prático.

Você pode ler o começo do capítulo 1 e ver o sumário completo na página do livro.