O domínio antes do desenho técnico

Arquitetura começa quando a empresa decide o que é o seu negócio e o que é apoio. Um domínio é a área onde a linguagem do negócio tem significado próprio: pedido, apólice, matrícula, laudo. Quando duas áreas usam a mesma palavra para coisas diferentes, existe uma fronteira mal desenhada, e cada integração futura vai carregar essa confusão adiante.

Separar domínio central de domínio de apoio é uma decisão de investimento. O núcleo diferencia a empresa e merece modelo próprio, código próprio e time próprio. O apoio (emissão de nota, autenticação, cadastro) deve ser comprado ou resolvido com o menor esforço possível. Arquiteturas que tratam tudo como central produzem sistemas caros de mudar em qualquer ponto, porque cada alteração relevante atravessa áreas que nunca precisariam conversar.

Modularidade: a fronteira que se paga

Módulo é unidade de mudança. Um módulo bem fechado pode ser reescrito sem que o resto do sistema saiba, desde que o contrato público dele permaneça. Já um conjunto de classes que compartilham tabelas e entidades entre si não é módulo, é um bloco único com nomes diferentes.

Critérios que ajudam a decidir se vale separar:

  • Times diferentes precisam evoluir a mesma área em ritmos distintos.
  • Regras de negócio mudam com frequência desigual (precificação muda toda semana, cadastro muda uma vez por ano).
  • Requisitos de disponibilidade e de carga são desproporcionais entre as partes.
  • O custo de uma falha em uma parte não deveria derrubar a outra.

Separar sem esses motivos costuma gerar mais operação e menos velocidade. Serviços distribuídos sobre um domínio mal entendido apenas transformam acoplamento de código em acoplamento de rede, com latência, repetição de chamadas e consistência eventual no lugar de uma transação.

Integrações como contrato

Toda integração tem dois lados que mudam em momentos diferentes. Por isso o contrato precisa ser explícito: payload versionado, semântica de erro definida, idempotência em operações que podem ser repetidas e um limite claro de quem é dono do dado. Use chamada síncrona quando a resposta é necessária para concluir a operação; use assíncrona quando o efeito pode acontecer depois, com fila e reprocessamento.

Exemplo: uma distribuidora de médio porte que atende o interior paulista fechava o pedido no ERP e dava baixa de estoque no WMS em chamadas encadeadas dentro da mesma requisição do vendedor. No fechamento do mês, quando o WMS ficava lento, o vendedor via erro, refazia o pedido e o ERP registrava duplicidade. O estoque físico e o sistêmico divergiam, e o time de logística gastava o dia seguinte em conferência manual. A correção não foi trocar de ferramenta: o pedido passou a ser aceito com chave de idempotência, a baixa de estoque virou evento assíncrono com reprocessamento e o status ficou visível ao vendedor. Mesmo domínio, agora com fronteiras e contratos explícitos.

Na prática

Para quem mantém software em produção, arquitetura se prova no incidente e na fila de mudanças. Um roteiro mínimo:

  • Nomeie as fronteiras com a linguagem do negócio e registre em uma página o que cada módulo oferece e o que ele não faz.
  • Trate todo contrato de integração como API pública: versione, documente, defina idempotência e erros esperados.
  • Meça acoplamento pelo esforço de mudança: se alterar uma regra exige tocar em quatro módulos, a fronteira está no lugar errado.
  • Prefira a chamada em processo até existir motivo concreto (time, carga, disponibilidade) para distribuir.
  • Registre decisões de arquitetura com data e contexto, para que a próxima pessoa entenda o porquê antes de desfazer no escuro.

Arquitetura boa não é a mais avançada: é a que permite mudar uma parte do negócio sem renegociar o sistema inteiro.