O domínio define as fronteiras, não a estrutura técnica

Arquitetura corporativa começa com uma pergunta de negócio: quais regras precisam mudar juntas e quais podem evoluir separadamente? O domínio é o conjunto de regras que a empresa executa todos os dias: política de preço, limite de crédito, cálculo de frete, elegibilidade de desconto, ciclo de faturamento. Essas regras compartilham uma característica: mudam por decisão de negócio, não por decisão técnica.

Quando o desenho dos módulos nasce da estrutura do banco, das telas ou do framework, o resultado tende a ser o inverso. Uma alteração de política comercial vira uma sequência de ajustes em pontos que ninguém sabia que existiam. A fronteira correta é aquela que pode ser descrita em uma frase e apontada em um único lugar do sistema.

Um exercício útil: listar as regras que mais mudam e identificar quem as mantém hoje. Se a mesma pessoa precisa mexer em cadastro, cálculo e emissão para alterar uma faixa de desconto, a fronteira está no lugar errado, independentemente do nome da pasta ou do serviço.

Modularidade se mede pelo custo de mudança

Modularidade não é quantidade de pastas nem número de serviços. É o quanto uma alteração em uma parte do sistema pode quebrar outra. Um monólito pode ser modular; um conjunto de microsserviços pode ser um emaranhado acoplado. O que define é a direção das dependências e a clareza dos contratos internos.

Critérios que ajudam a avaliar o desenho:

  • Cada módulo tem um dono identificável e uma responsabilidade escrita em linguagem de negócio.
  • Regras de negócio podem ser testadas sem banco, fila ou interface.
  • Um módulo não escreve nas tabelas de outro; a conversa acontece por interface ou evento.
  • Seria possível extrair um módulo para um processo separado sem reescrever suas regras.
  • Dependências apontam para o domínio, e não do domínio para a biblioteca da moda.

O teste decisivo é o cenário de mudança. Se alterar o cálculo de comissão exige tocar em faturamento, no portal do cliente e no relatório gerencial, o módulo é uma divisão de arquivos, não de responsabilidades.

Considere uma distribuidora de insumos que atende indústria e revenda com tabelas de preço diferentes. A política de desconto por volume estava replicada no ERP, no portal de pedidos e no aplicativo da força de vendas. Cada negociação especial exigia três alterações e uma conferência manual antes do fechamento. Concentrar a regra em um módulo de precificação, exposto por uma interface única, não reduziu o número de telas, mas eliminou a divergência entre canais e permitiu mudar a política uma vez só.

Integrações: contrato antes da conexão

Integração não é ligar dois sistemas. É estabelecer um contrato com significado de negócio, versão, tratamento de falha e semântica explícita de tempo. Sem isso, cada ponta cria sua própria interpretação do dado, e o acoplamento aparece justamente onde ninguém olha: no formato do payload e no momento em que a informação chega.

Perguntas que deveriam anteceder qualquer integração nova:

  • Qual evento de negócio este contrato representa e quem é o dono do dado?
  • O que acontece se a mensagem chegar duas vezes, fora de ordem ou atrasada?
  • Como o erro é comunicado e quem é responsável por reprocessar?
  • Existe versionamento, ou a mudança de um campo quebra silenciosamente o consumidor?

Respostas vagas nessas quatro perguntas custam mais caro do que a integração em si. Um pedido duplicado gerado por reenvio automático, ou um estoque desatualizado por evento perdido, viram conciliação manual e desgaste entre as áreas.

Na prática

Para quem mantém software em produção, três hábitos sustentam esse desenho. Primeiro, tratar cada mudança de regra de negócio como oportunidade de consolidar a fronteira: se a alteração precisa ser feita em dois lugares, registre isso como dívida de arquitetura e não como rotina. Segundo, exigir contrato explícito nas integrações antes de liberar acesso direto a banco ou a tabela compartilhada, porque atalho de integração é o acoplamento mais difícil de desfazer depois. Terceiro, documentar o domínio em linguagem de negócio, com nomes que o time de operação reconheça, para que a decisão de modularização não dependa de quem escreveu o código original.

Arquitetura, nesse sentido, é uma decisão contínua sobre onde cada regra mora. O sistema envelhece bem quando essa resposta continua óbvia meses depois da entrega.