Uma fronteira de serviço pelos padrões de acesso a dados

Uma fronteira de serviço é confiável quando cada lado consegue confirmar suas próprias alterações sem pedir que o outro participe da mesma transação. Organogramas, mapas de capacidades e os substantivos usados em uma oficina podem sugerir onde procurar. O banco de dados mostra se a separação proposta sobreviverá ao contato com a produção.

Eu começo pelos padrões de acesso a dados porque sistemas antigos registram seus contratos reais em leituras, gravações, bloqueios, gatilhos, rotinas e procedimentos de recuperação. A parte difícil é separar um acoplamento acidental de uma invariante de negócio. Uma tela que lê nomes de clientes ao lado de faturas cria uma dependência de apresentação. Uma rotina de lançamento que atualiza uma fatura, uma entrada contábil e um saldo de crédito no mesmo commit pode codificar uma invariante que não tolera sucesso parcial. Essas duas dependências merecem tratamentos diferentes.

O resultado útil não é um diagrama de domínios bonito. É um pacote de evidências: um mapa de propriedade das tabelas, uma matriz das tabelas gravadas na mesma transação, um mapa das leituras que cruzam domínios candidatos e uma lista curta das invariantes que explicam os agrupamentos mais fortes. Com essas evidências, uma equipe pode escolher uma fronteira e declarar exatamente o que deve mudar antes da primeira implantação independente.

Comece pelas transações, não pelos nomes das tabelas

Tabelas gravadas na mesma transação são o sinal inicial mais forte porque a aplicação atualmente trata essas alterações como uma unidade de sucesso ou falha. Se invoice, ledger_entry e customer_balance mudam repetidamente sob o mesmo identificador de transação, separá-las entre serviços substituiria um commit local por coordenação, compensação ou uma regra de negócio alterada.

Os nomes enganam. Uma tabela chamada customer pode guardar a identidade da conta, a situação de crédito, preferências de entrega e um total de vendas desnormalizado. Uma tabela chamada order_status pode funcionar como fila compartilhada entre expedição e faturamento. Prefixos costumam refletir a equipe que criou uma tabela, e não o comportamento que hoje depende dela. Até chaves estrangeiras descrevem apenas relações referenciais declaradas. Elas não dizem nada sobre um programa noturno que lê três tabelas, grava outras duas e precisa reiniciar depois da linha 80.000.

Defina uma transação como o banco a enxerga: as instruções entre begin e commit ou rollback, inclusive instruções emitidas por gatilhos e procedimentos armazenados. Cada instrução em autocommit forma sua própria transação. Programas em lote precisam de uma identidade adicional para a execução e o ponto de controle, pois um laço que confirma a cada 500 registros carrega uma operação de negócio maior do que cada transação individual do banco.

Capture pelo menos estes campos em cada acesso observado:

• identificador da transação e horário
• executável, rotina, rota ou ponto de entrada
• tabela e tipo de operação
• linhas afetadas ou uma faixa aproximada de cardinalidade
• cadeia de chamadas ou nome do procedimento armazenado, quando disponível

Não comece atribuindo cada tabela a um domínio. Primeiro reúna fatos sem forçá-los a entregar a resposta desejada. Os rótulos de domínio vêm depois que os agrupamentos de gravação conjunta aparecem. Essa ordem impede que o vocabulário da oficina contamine a medição.

Monte uma matriz de cogravação que exponha o trabalho atômico

Uma matriz de cogravação conta quantas vezes duas tabelas recebem gravações na mesma transação do banco. Ela transforma milhares de rastros em um grafo ponderado: tabelas são nós, e uma aresta liga duas tabelas quando pelo menos uma transação grava ambas. O peso da aresta pode registrar a quantidade de transações, as linhas afetadas ou a parcela das gravações de cada tabela envolvida no par.

Suponha que rastros normalizados sejam armazenados em uma tabela chamada data_access:

create table data_access (
  captured_at timestamp not null,
  transaction_id varchar(100) not null,
  entry_point varchar(200) not null,
  table_name varchar(200) not null,
  operation varchar(10) not null,
  rows_affected bigint
);

with writes as (
  select distinct transaction_id, table_name
  from data_access
  where operation in ('INSERT', 'UPDATE', 'DELETE')
), pairs as (
  select a.table_name as table_a,
         b.table_name as table_b,
         count(*) as shared_transactions
  from writes a
  join writes b
    on a.transaction_id = b.transaction_id
   and a.table_name < b.table_name
  group by a.table_name, b.table_name
)
select table_a, table_b, shared_transactions
from pairs
order by shared_transactions desc;

A saída tem o formato table_a | table_b | shared_transactions. Os maiores valores merecem análise, mas contagens brutas não bastam. Uma rotina de manutenção pode dominar o volume sem codificar nenhuma invariante visível ao usuário. Um lançamento raro de encerramento anual pode carregar o requisito atômico mais forte do sistema. Inclua o ponto de entrada no agrupamento e compare o mesmo par entre solicitações online, rotinas agendadas, importações e ferramentas de operadores.

Normalize o peso nas duas direções. Se 98 por cento das gravações em customer_balance acontecem junto com ledger_entry, essa aresta importa mesmo quando as transações formam uma pequena parcela de toda a atividade contábil. Eu uso duas medidas condicionais: transações que gravam A e também B, divididas por todas as transações que gravam A; e o inverso. Um resultado assimétrico costuma revelar uma tabela satélite que pertence a um agregado maior.

A amostragem deve preservar as fronteiras das transações. Capturar uma em cada cem instruções SQL destrói a evidência, porque a amostra pode manter uma metade da cogravação e descartar a outra. Selecione transações completas pelo identificador ou capture todas as transações de pontos de entrada escolhidos. Mascare valores se necessário, mas preserve nomes de tabelas, tipos de operação, horários e associação à transação.

Separe invariantes de negócio de hábitos de implementação

Um agrupamento denso de cogravações propõe uma fronteira, mas não a prova. A equipe precisa explicar por que cada aresta forte existe e o que quebraria se as duas gravações fossem confirmadas separadamente. Essa explicação distingue uma invariante de negócio de um código que por acaso usa a mesma conexão.

Peça uma frase que descreva a falha. Para uma fatura e sua entrada contábil, poderia ser: “O financeiro nunca pode reconhecer uma fatura sem os lançamentos correspondentes de débito e crédito.” Para um pedido e seu registro de auditoria: “Os operadores precisam de um registro de quem alterou o pedido.” O primeiro caso pode exigir estado atômico ou um modelo de lançamento redesenhado com cuidado. O segundo muitas vezes pode virar um evento durável ou uma outbox no banco, sem tornar a tabela de auditoria parte da propriedade do pedido.

Classifique cada aresta de cogravação em um de quatro motivos:

1. Uma invariante de negócio exige que todas as alterações tenham sucesso em conjunto.
2. Uma limpeza referencial ou lógica em cascata mantém coerentes os dados armazenados.
3. Um valor derivado ou índice é atualizado de forma síncrona para acelerar leituras.
4. O código reutilizou uma transação porque as tabelas estavam próximas.

Somente o primeiro motivo é uma evidência forte de que as tabelas pertencem à mesma fronteira de consistência. O segundo pode desaparecer quando um serviço é dono da exclusão e publica esse fato. O terceiro costuma ser um problema de projeção. O quarto é dívida de migração.

Gatilhos exigem atenção especial porque os rastros da aplicação podem escondê-los. Uma rotina pode parecer atualizar shipment, enquanto um gatilho ajusta inventory, insere stock_movement e grava em uma fila de integração. Leia as definições dos gatilhos e o corpo dos procedimentos armazenados, depois atribua suas gravações à transação e ao ponto de entrada que as iniciou. Caso contrário, a fronteira proposta falhará no primeiro caso de produção que acionar esse comportamento oculto do banco.

Bloqueios e tratamento de erros fornecem evidências adicionais. Um código que tenta novamente um deadlock entre duas tabelas, converte a violação de uma restrição em mensagem de negócio ou reverte as duas alterações depois de uma validação malsucedida provavelmente depende do destino compartilhado delas. Documente a restrição ou regra de recuperação exata. “Estas tabelas estão acopladas” é vago demais para orientar uma migração.

Trate leituras entre domínios como outro tipo de dívida

Uma leitura entre domínios candidatos não invalida automaticamente a fronteira. Leituras podem usar APIs, projeções replicadas, caches, snapshots ou repositórios analíticos sem coordenar commits. A pergunta de projeto é quão recentes e completos os dados precisam estar quando o leitor toma uma decisão.

Monte uma matriz de leitura depois que surgirem os possíveis proprietários das gravações. As linhas representam pontos de entrada e as colunas, domínios propostos. Cada célula registra tabelas lidas, frequência, cardinalidade e se o mesmo ponto de entrada grava em algum lugar. Dê atenção especial às leituras de decisão, cujo resultado determina uma gravação posterior. Um relatório que junta faturamento e clientes pode tolerar uma projeção atrasada. Uma verificação de crédito antes de aprovar um novo pedido talvez exija dados atuais ou um protocolo de reserva.

O padrão perigoso consiste em ler o domínio B, calcular no código da aplicação e depois gravar no domínio A supondo que B não mudou. Um monólito local pode esconder essa corrida dentro de uma transação de banco bloqueando as linhas de B. Depois da separação, uma chamada síncrona de API devolve um valor, mas não estende a transação do chamador pela rede. O valor pode mudar antes que A faça o commit.

Registre uma classe de atualização para cada leitura transversal:

• exata no momento da decisão
• atraso limitado com um máximo declarado
• último valor conhecido com conciliação
• snapshot histórico
• somente exibição

Essa classificação transforma a dependência vaga “pedidos precisam de dados do cliente” em contrato. Nomes de clientes usados apenas para exibição podem ficar em uma projeção de pedidos. Uma verificação de limite de crédito pode exigir que o domínio de clientes possua uma reserva, de modo que o serviço de pedidos peça a reserva de capacidade em vez de buscar um número e tomar a decisão sozinho.

Junções amplas para relatórios não devem ditar fronteiras transacionais. Mova-as para uma projeção de relatórios alimentada pelas alterações de seus proprietários ou mantenha uma réplica de leitura durante a transição. Forçar serviços operacionais a chamar uns aos outros linha por linha para manter um relatório antigo cria uma junção de rede lenta e espalha falhas de disponibilidade. Relatórios precisam de um produto de dados explícito, não de acesso acidental a todo esquema operacional.

Views e consultas armazenadas podem esconder a travessia. Expanda cada view até suas tabelas base ao montar a matriz, mas mantenha o nome da view como contrato do consumidor. Uma dúzia de programas pode ler open_account_summary sem saber que ela junta contas a receber, situação do cliente e contestações. Substituir a view uma vez pode ser mais simples do que alterar cada programa, mas sua regra de atualização ainda precisa de proprietário. Meça se os chamadores filtram, agregam ou buscam todo o resultado para decidir entre projeção, endpoint de consulta ou exportação em massa.

Examine também leituras negativas. O código muitas vezes pergunta se uma linha não existe: nenhuma fatura em aberto, nenhum bloqueio ativo, nenhuma solicitação anterior com esta referência. O atraso de replicação torna a ausência especialmente perigosa, pois uma projeção desatualizada parece exatamente uma permissão para seguir. Coloque essas verificações junto das outras leituras de decisão e nomeie a autoridade capaz de respondê-las. Se a verificação protege unicidade ou limite de gasto, leve a decisão para essa autoridade em vez de copiar a tabela e torcer para vencer a corrida da replicação.

O comportamento diante de falhas de leitura também faz parte do contrato. Quando o proprietário remoto está indisponível, o chamador precisa rejeitar, usar um valor antigo dentro de um limite, enfileirar o trabalho ou prosseguir com um risco explícito. A escolha correta depende da regra de negócio. Uma política genérica de novas tentativas esconde a decisão até uma pane, quando os operadores têm menos espaço para raciocinar.

Uma fronteira falha quando a invariante a atravessa

O teste prático de uma separação proposta é simples: cada lado consegue aceitar ou rejeitar seus próprios comandos usando dados que possui e preservando as regras de negócio declaradas? Se um comando do lado A precisa que o lado B participe do mesmo commit, a fronteira não está pronta.

Considere uma rotina de pedido que executa estas ações em uma transação:

1. Ler o crédito disponível do cliente com bloqueio de linha.
2. Inserir o pedido e seus itens.
3. Aumentar a exposição de crédito comprometida do cliente.
4. Inserir um registro de auditoria e confirmar.

Um organograma pode colocar a gestão de clientes e a gestão de pedidos em departamentos distintos. Uma extração direta transformaria as etapas dois e três em uma transação distribuída. Chamar primeiro o serviço de clientes não resolve o problema: a inserção do pedido pode falhar depois do aumento da exposição. Chamá-lo por último cria o órfão oposto. Tentar novamente sem critério arrisca uma contagem duplicada.

Há três opções honestas. Manter exposição de crédito e aceitação do pedido dentro da mesma fronteira. Mover a decisão para uma reserva de crédito pertencente ao lado do cliente, com identificador de reserva idempotente e operações explícitas de confirmação ou liberação. Ou mudar a regra de negócio para permitir divergência temporária, depois conciliar e colocar os pedidos afetados em espera. Cada opção altera a propriedade ou a semântica. Um broker de mensagens sozinho não muda nenhuma delas.

A abordagem de reserva precisa de estados e comportamento temporal, não de um nome de evento otimista. reserve deve retornar o mesmo resultado para o mesmo identificador. confirm deve tolerar repetições. A expiração deve considerar uma confirmação atrasada. Os operadores precisam enxergar reservas que nunca chegam ao estado final. Se a organização não consegue declarar essas regras, não removeu a transação distribuída, apenas mudou o nome da incerteza.

Por isso discordo de “separar por capacidade de negócio” como método completo. O conselho é popular porque capacidades produzem diagramas que executivos e engenheiros conseguem discutir juntos. Ele é útil para gerar candidatos. Como teste final, está errado porque um mapa de capacidades não revela escopo de commit, comportamento de gatilhos, leituras de decisão bloqueadas nem semântica de reinício.

Rotinas em lote revelam o que os rastros online omitem

O tráfego online raramente cobre o contrato completo de um sistema antigo. Fechamento mensal, liquidação, importações, reprocessamentos e correções de operadores muitas vezes atravessam tabelas que solicitações comuns nunca tocam. Uma fronteira escolhida apenas com rastros HTTP pode parecer limpa até a primeira execução agendada.

Faça um inventário de todo executável que se conecta ao banco, inclusive scripts iniciados por agendadores, rotinas armazenadas, clientes desktop, macros de planilhas e utilitários de suporte. Relacione sessões do banco aos nomes dos executáveis ou às credenciais quando possível. Credenciais compartilhadas dificultam isso, então combine metadados de sessão, definições do agendador, busca no código e registros de auditoria do banco.

A cadência de commits no lote importa. Um programa que lê todas as faturas não lançadas, cria entradas contábeis, marca linhas de origem e confirma a cada 500 itens possui pelo menos três escopos:

• a transação do banco para cada bloco
• o ponto de controle usado para retomar a execução
• a exigência de negócio de todo o período de lançamento

Separar serviços pode preservar commits por bloco e quebrar o reinício. Imagine que o novo serviço contábil aceite 430 entradas antes de o chamador falhar. O programa antigo reinicia do último ponto de controle e envia essas entradas outra vez. Sem um identificador de origem estável e aceitação idempotente, o destino lança duplicatas. Com idempotência, mas sem conciliação, a origem ainda pode mostrar 70 itens pendentes mesmo que o livro já os tenha aceitado.

Percorra um caminho real de reinício para cada lote importante. Registre onde ele cria o ponto de controle, quais gravações acontecem antes, como reconhece trabalho anterior, o que os operadores verificam e como repara uma execução parcial. Depois atribua a propriedade desse processo de recuperação. Diagramas de serviços tendem a omitir procedimentos operacionais, embora esses procedimentos muitas vezes guardem a única definição funcional de consistência.

Rotinas raras precisam ser ponderadas pelas consequências e também pela frequência. Eu marco uma aresta como significativa para a operação quando uma falha bloqueia fechamento, folha de pagamento, expedição, relatório regulatório ou outro evento de negócio nomeado. Isso é julgamento, não uma pontuação matemática inventada. A intenção é impedir que atualizações de login em alto volume escondam uma invariante contábil de baixo volume.

Escolha a propriedade das tabelas antes das APIs

Toda tabela mutável precisa de um proprietário proposto antes do projeto das APIs. O acesso de gravação compartilhado permite que os dois serviços mantenham os atalhos antigos, então a fronteira existe apenas nos diagramas de implantação. Propriedade significa que um serviço decide transições de estado válidas, realiza gravações e cuida de reparos.

Crie um cadastro com estas colunas: tabela, proprietário proposto, pontos de entrada que gravam, agrupamento de cogravação, leituras de decisão transversais, gatilhos, rotinas em lote e invariante não resolvida. Atribua também as tabelas derivadas. “Compartilhado” é um estado temporário de migração com condição de saída, não um domínio.

Depois procure todos os caminhos de gravação na árvore de código. A busca estática encontra instruções e mapeamentos ORM que os rastros perderam. Rastros dinâmicos encontram SQL gerado e chamadas de procedimentos pouco óbvias que a busca não viu. Nenhuma fonte basta sozinha. Compare as duas e explique as diferenças, principalmente utilitários inativos que ainda possuem credenciais de produção.

Comandos de API devem expressar decisões pertencentes ao serviço chamado. reserveCredit(orderId, amount) é mais forte que getAvailableCredit(customerId) seguido de um cálculo no chamador. postInvoice(invoiceId, lines) é mais forte que expor operações CRUD para tabelas contábeis. O comando permite que o proprietário proteja sua invariante enquanto seu armazenamento muda.

Leituras também precisam de propriedade, mesmo quando os dados são copiados. Uma projeção pode conter nome e situação do cliente dentro do serviço de pedidos, mas o serviço de clientes continua sendo a autoridade. Armazene o identificador e a versão da origem ou a posição do evento para que a conciliação detecte atualizações perdidas ou fora de ordem. Decida o que o leitor faz quando a projeção está atrasada: continuar, avisar, rejeitar ou buscar de forma síncrona. Não deixe essa escolha para o engenheiro que atender o primeiro incidente.

Permissões no banco podem impor a fronteira antes da extração física. Dê direitos de gravação ao futuro proprietário e transforme os outros gravadores em chamadores por etapas controladas. Audite tentativas negadas durante os testes. Uma divisão de esquemas sem mudanças de permissão é cosmética, pois qualquer rotina antiga ainda pode atravessá-la.

Avalie fronteiras candidatas pelo trabalho exigido

Uma avaliação útil estima o custo da migração e o risco operacional; ela não finge descobrir arquitetura por meio de aritmética. Eu comparo os candidatos com o mesmo conjunto de perguntas observáveis e mantenho as evidências brutas ao lado de cada classificação.

Para cada fronteira proposta, registre:

• quantidade e importância para o negócio das transações que gravam nos dois lados
• leituras de decisão que exigem estado remoto atual
• fluxos em lote e de recuperação que cruzam a linha
• tabelas com vários gravadores ativos
• relatórios e exportações que precisam de um novo caminho de leitura

Use uma escala ordinal pequena, como ausente, administrável, substancial e impeditivo. Evite combinar tudo em um único número decimal. Dois candidatos com o mesmo total podem carregar riscos bem diferentes: um pode exigir várias projeções simples, enquanto o outro tem uma única invariante financeira impeditiva. A segunda controla a decisão.

A melhor primeira fronteira costuma ter gravações coesas e leituras sem complicação. Um agrupamento possui suas atualizações, enquanto consumidores externos principalmente exibem ou relatam seus dados. Esse formato comporta uma outbox, projeções e uma pequena superfície de comandos. A pior fronteira tem poucas tabelas óbvias, mas muitas leituras de decisão atuais e gravadores compartilhados. Um esquema pequeno não significa pouco acoplamento.

As janelas de tempo mudam o resultado. Analise períodos de negócio representativos, incluindo execuções agendadas e ações incomuns de operadores. Compare dias normais com períodos de fechamento ou liquidação. Uma matriz criada em uma tarde tranquila subestima o acoplamento. A análise do código deve complementar a janela listando pontos de entrada ausentes no tráfego capturado.

Mantenha a incerteza visível. Marque tabelas com rastros incompletos, nomes dinâmicos, gravadores externos ou procedimentos desconhecidos. Uma aresta não resolvida não vale zero. Eu adiaria uma decisão de fronteira ao redor de uma rotina contábil desconhecida antes de confiar em um grafo limpo construído com evidências parciais.

Prove a fronteira com comportamento em sombra

Uma fronteira merece confiança quando os proprietários propostos conseguem reproduzir os resultados atuais em cargas registradas sem compartilhar gravações. Antes de enviar comandos de produção para novos serviços, execute a arquitetura candidata em sombra e compare suas transições de estado com as do original.

O harness deve reproduzir comandos ou tráfego capturado com identificadores estáveis, observar efeitos no banco e comparar resultados de negócio em vez da ordem física das linhas. Normalize horários, identificadores gerados e outros campos não determinísticos. Compare totais, estados, fatos emitidos, classes de erro e resultados de reinício. Uma divergência precisa de explicação classificada, não de um percentual geral de aprovação.

Inclua casos que exercitem a fronteira:

1. comandos bem-sucedidos com gravações restritas a um proprietário
2. comandos rejeitados depois de uma reserva ou validação remota
3. novas tentativas após timeouts e entrega duplicada
4. reinício de lote a partir de cada posição de controle
5. dados de projeção atrasados ou ausentes

O tráfego registrado traz realismo, mas raramente contém todas as falhas. Adicione falhas controladas entre as etapas que antes compartilhavam um commit. Pare o consumidor depois que ele gravar e antes da confirmação de recebimento. Atrase uma atualização de projeção. Repita um identificador de comando. Faça uma reserva expirar quando a confirmação chegar. Esses testes mostram se o novo projeto tem comportamento de recuperação explícito.

CodeHero usa um harness de paridade contra tráfego de produção registrado ao reescrever sistemas antigos. Isso se encaixa neste trabalho porque mudanças de arquitetura só são confiáveis quando o comportamento continua responsável perante o original. As evidências devem permanecer legíveis para os engenheiros do cliente: identidade da entrada, resultado antigo, resultado novo, diferenças normalizadas e a regra usada para aceitá-las ou rejeitá-las.

Não exija igualdade byte por byte quando a migração altera a arquitetura de propósito. Exija igualdade para o comportamento prometido e aceitação documentada para diferenças intencionais. Se a ordem de lançamento mudar, mas saldos, referências e regras de recuperação continuarem corretos, a sequência física pode não importar. Se um erro virar sucesso depois de um timeout, isso importa mesmo quando as contagens finais das tabelas forem iguais.

A primeira extração deve remover uma fronteira transacional

Escolha o primeiro serviço somente quando puder nomear suas tabelas, comandos, fatos publicados, leituras transversais e regras de recuperação. A equipe deve conseguir apontar cada gravação antiga entre fronteiras e dizer se ela foi removida, convertida em comando com proprietário ou aceita como restrição temporária de migração com uma condição de saída datada.

Eu uso uma única condição de liberação: nenhum caminho de produção pode gravar tabelas nos dois lados da fronteira proposta. Gravações duplas temporárias dentro de um adaptador de migração ainda contam como transversais. Elas precisam de idempotência, comparação e plano de remoção, mas não comprovam propriedade independente.

A sequência de extração segue as evidências. Primeiro imponha um gravador por tabela. Depois substitua leituras de exibição e relatórios por projeções ou acesso transitório aprovado. Mova leituras de decisão para comandos do proprietário ou protocolos explícitos de reserva. Por fim, altere as fronteiras de implantação e armazenamento. Inverter essa ordem cria chamadas de rede enquanto o antigo acoplamento de dados permanece.

Mantenha as matrizes de cogravação e leitura depois da extração. Elas se tornam verificações de regressão. Um novo gravador compartilhado, um comando que começa a ler estado remoto atual ou uma rotina em lote que contorna a API deve provocar uma revisão. Diagramas de arquitetura envelhecem em silêncio; as evidências de acesso mostram a violação.

Alguns sistemas contêm uma invariante que deve continuar local. Aceite esse resultado. Um serviço maior com uma transação coerente é mais barato e seguro do que dois serviços mantidos juntos por chamadas síncronas, bloqueios distribuídos e reparos de operadores. O objetivo é permitir mudança independente onde as regras de negócio autorizam, não obter o maior número possível de implantáveis.

Quando as evidências apoiam uma separação, a fronteira deixa de ser uma opinião sobre substantivos. Ela se torna uma afirmação que pode ser refutada: estas tabelas mudam juntas, estas leituras toleram este contrato, estes comandos preservam a invariante e estes testes de falha demonstram recuperação independente. Isso basta para passar de uma fronteira de oficina a uma fronteira de produção.