O domínio define onde o sistema pode ser cortado
Arquitetura de software corporativo começa antes da primeira linha de código, na leitura do negócio. Domínio, aqui, não é a lista de entidades do banco. É o conjunto de regras que a empresa não pode errar: como o preço é formado por canal, quando o crédito do cliente bloqueia o pedido, qual é o prazo real de entrega por região, o que acontece quando o estoque reservado não confirma.
Numa distribuidora de autopeças, essas regras costumam nascer espalhadas. A política de desconto progressivo existe no cadastro de clientes, no cálculo do pedido e num relatório mantido em planilha. Quando a diretoria muda a faixa de desconto do canal de oficinas, a alteração precisa ser feita em três lugares e testada em quatro. O custo não está no código novo, está na confiança de que nada quebrou.
Um sistema com domínio bem delimitado trata a regra de precificação como um componente único, com um ponto de entrada claro e testes próprios. O pedido consulta essa regra, não a reimplementa. A mudança de política comercial passa a ser uma alteração localizada, com escopo conhecido.
Modularidade é sobre o que muda junto
Módulo não é pasta no projeto. É unidade de mudança. O critério prático é simples: o que muda pela mesma razão fica junto, o que muda por razões diferentes fica separado. Um módulo de faturamento e um módulo de logística podem compartilhar o mesmo banco e continuar sendo módulos distintos, desde que nenhum acesse as tabelas internas do outro.
Sinais de que a modularidade é apenas cosmética:
- a mesma regra de negócio aparece duplicada em dois módulos, com pequenas diferenças;
- um módulo importa entidades internas de outro para montar suas consultas;
- uma transação de banco atravessa a fronteira entre módulos;
- qualquer alteração pequena exige deploy do sistema inteiro.
Nenhum desses sinais é fatal isoladamente. Juntos, indicam que a fronteira existe no diagrama e não no código. O efeito aparece no dia em que dois times precisam mexer no mesmo assunto ao mesmo tempo.
Integrações são contratos, e contratos envelhecem
Integração não é uma chamada HTTP que funciona. É um contrato: quem é dono do dado, qual o formato acordado, o que acontece quando o outro lado falha, como reprocessar sem duplicar efeito. Na mesma distribuidora, a integração com o ERP costuma ser o ponto mais frágil, porque o payload do ERP vira o modelo interno da aplicação nova. Quando o ERP muda um campo, o domínio inteiro sente.
A prática que reduz esse acoplamento é traduzir na fronteira. O payload externo entra por um adaptador, é convertido para o modelo do domínio e só então circula. Do lado da saída, vale o mesmo: o domínio não conhece o formato de ninguém. Além disso, integração precisa de idempotência (reprocessar a mesma mensagem sem gerar pedido duplicado), versionamento do contrato e um lugar visível para as falhas.
Na prática
Para quem mantém software em produção, três rotinas sustentam essas decisões:
- Manter um mapa das regras de negócio críticas e de onde cada uma vive no código. Se a resposta for "em vários lugares", existe dívida de domínio.
- Revisar fronteiras a cada mudança relevante: a alteração tocou um módulo ou atravessou três? O segundo caso é sinal de corte errado.
- Tratar cada integração como contrato versionado, com adaptador, idempotência e monitoramento de falhas.
Arquitetura, nesse sentido, é a decisão de onde colocar as fronteiras e como atravessá-las. O resto é consequência.