O domínio manda na arquitetura

Arquitetura começa com uma pergunta de negócio: quais decisões do dia a dia da empresa o sistema precisa representar com fidelidade? Isso é o domínio. Em uma distribuidora de autopeças, por exemplo, o domínio inclui política de preço por canal, regras de crédito para cliente lojista, reserva de estoque por depósito e substituição por peça equivalente quando falta o código original. Nada disso é detalhe de tela: são regras que, se ficarem espalhadas em controllers, relatórios e procedures, passam a divergir entre si.

Modelar domínio não é desenhar um diagrama bonito. É decidir vocabulário único e dono de cada regra. Quando a regra de "cliente inadimplente não reserva estoque" existe em um único lugar, mudar essa política vira uma alteração pequena, com teste, em vez de uma caça a seis pontos do código.

A consequência prática é direta: o código de domínio não deve depender de framework, banco ou protocolo HTTP. Ele depende apenas das suas próprias abstrações. É isso que permite trocar mensageria, ORM ou provedor de nuvem depois sem reescrever a regra de negócio.

Modularidade: limites que aguentam crescer

Modularidade é a decisão de onde colocar as fronteiras. Um erro comum é dividir o sistema por camadas técnicas (services, repositories, helpers) e chamar isso de modular. Fronteira útil é por capacidade de negócio: faturamento, estoque, crédito, catálogo, logística.

Critérios que ajudam a decidir:

  • Cada módulo expõe uma interface pública pequena e estável; o resto é interno e pode mudar sem aviso.
  • A comunicação entre módulos acontece por contratos explícitos (eventos ou chamadas de aplicação), nunca por acesso direto às tabelas do vizinho.
  • Dados de um módulo não são lidos por SQL direto de outro. Isso cria acoplamento invisível que só aparece em produção.
  • Um módulo deve poder ser testado sozinho, sem subir a aplicação inteira.

Modularidade não exige microsserviços. Um monolito modular bem delimitado resolve a maior parte dos casos corporativos com custo operacional menor. Separar em serviços só se justifica quando existe necessidade real de escala, times independentes ou isolamento de falha.

Integrações como contratos

Toda integração é uma fronteira com algo que você não controla: ERP fiscal, marketplace, adquirente, transportadora, sistema legado do cliente. O desenho correto trata essa fronteira como contrato, e não como chamada direta.

Na prática, defina um adaptador próprio que traduz o modelo externo para o modelo do seu domínio. Assim, quando o marketplace muda o formato do payload ou o ERP troca de versão, o impacto fica contido em um ponto, não na regra de negócio.

Além disso, integrações carregam suposições: o outro lado vai responder, vai responder rápido, vai responder uma única vez. Nenhuma delas é garantida. Timeout, falha parcial, resposta duplicada e indisponibilidade são comportamento normal, e a arquitetura precisa assumir isso desde o começo, com registro de tentativas, estado de sincronização por registro e trilha de auditoria.

Voltando à distribuidora: ao entrar em um marketplace, a empresa descobriu que a reserva de estoque era feita em quatro pontos diferentes, cada um com uma regra própria. A solução não foi reescrever o e-commerce, foi isolar a capacidade de estoque em um módulo com uma única porta de entrada e fazer o marketplace consumir essa porta. O efeito foi parar de vender peça que não existia e reduzir o tempo gasto investigando divergência de estoque entre canais.

Na prática

Para quem mantém software em produção, algumas decisões valem mais que qualquer diagrama:

  1. Nomeie o domínio. Um glossário com o significado acordado entre negócio e time técnico elimina boa parte das ambiguidades de requisito.
  2. Escolha fronteiras por capacidade de negócio e escreva a interface pública de cada módulo.
  3. Proíba acesso cruzado a dados entre módulos. Se precisar de um dado do vizinho, use a interface dele.
  4. Isole cada integração em um adaptador com contrato explícito, tratamento de falha e rastreabilidade.
  5. Documente as decisões arquiteturais e o motivo delas. Em dois anos, o custo maior não é o código legado, é a ausência de contexto sobre por que ele é assim.

Arquitetura boa é a que permite mudar uma regra de negócio sem medo de quebrar três áreas da empresa. Domínio claro, módulos com fronteiras honestas e integrações tratadas como contrato entregam exatamente isso.