Heatmap, fronteiras e erros clássicos

O BIAN entra no meu dia a dia por cinco portas, e convém saber qual você está abrindo.

Vocabulário comum: quando produto, risco e engenharia chamam a mesma coisa de "conta", "contrato" e "posição", a reunião gasta metade do tempo traduzindo. Customer Agreement e Position Keeping encerram a discussão.

Heatmap de sistemas: o inventário de aplicações projetado sobre os Service Domains. É o uso que mais rende em comitê de investimento e o centro desta aula.

Fronteiras de serviço: o mapa sugere onde um serviço termina e outro começa. Sugere, não manda; volto a isso adiante.

Desenho de APIs: os padrões funcionais e os action terms da aula 03 dão nome e forma a recurso, operação e evento sem reinventar convenção a cada squad.

Ferramentas de agentes: cada Service Domain é um candidato natural a tool com escopo delimitado; a aula 09 trata disso.

Os cinco usos compartilham uma regra: o mapa descreve capacidades de negócio, não software. Quem esquece isso produz o primeiro erro clássico da lista que fecha a aula.

O caso é fictício: uma emissora de cartões de porte médio que também operava adquirência e decidiu sair desse negócio. Pegue os Service Domains da área de cartões e, para cada um, registre três dados: quais sistemas o cobrem, quanta dor ele gera (incidentes, fila de mudanças, retrabalho) e quanto custa manter. A cor sai desses três dados, não da opinião do dono do sistema.

Pintado o mapa, a decisão por domínio segue um critério explícito, escrito no topo da planilha para ninguém discutir caso a caso:

• Construir quando o domínio é diferencial competitivo. Na emissora fictícia, Fraud Detection e Customer Offer: o modelo de risco e a oferta personalizada são o que o cliente percebe.
• Comprar quando é commodity de rede ou regulada. Card Clearing, Card Network Participant Facility e Payment Settlement: ninguém ganha cliente por liquidar melhor com a bandeira.
• Manter quando funciona bem e muda pouco. Card Authorization e Card Transaction Tracking rodam há anos com incidente raro; mexer ali é risco sem retorno.
• Aposentar quando o domínio saiu do negócio. Merchant Acquiring Facility e Card Terminal Administration deixam de existir na operação, e o plano de saída vira item de roadmap com dono e data.

O heatmap não entrega a decisão pronta, entrega a conversa certa: quatro verbos, um critério e um mapa que todo mundo lê.

Service Domain é fronteira candidata de serviço, não fronteira obrigatória. O BIAN desenha cada domínio para ser autônomo; isso o torna um bom ponto de corte, mas não quer dizer que cada corte deva virar um deploy separado.

Eu agrupo domínios por três eixos: time (quem opera junto implanta junto), taxa de mudança (o que muda toda semana não convive bem com o que muda uma vez por ano) e risco (o que derruba autorização não pode dividir processo com relatório gerencial). Na emissora fictícia, Card Authorization e Card Transaction Tracking podem viver no mesmo serviço: mesmo time, mesma cadência, mesmo plantão.

Separo quando um de três sinais aparece: escala diferente (autorização em milissegundos, faturamento em lote noturno), falha que precisa ser isolada (fraude fora do ar não pode travar a compra) ou auditoria que exige trilha própria (Customer Consent e tudo que a LGPD toca).

Para eventos, uma convenção só: Behavior Qualifier mais verbo no passado. AmountBlockInitiated diz qual qualificador mudou e qual action term aconteceu. Quem recebe o evento sabe onde ele nasceu no mapa sem abrir documentação. Aplique a mesma fórmula aos seus Behavior Qualifiers e evite verbos genéricos como Updated quando o action term existe.

Tratar o mapa como planta: o Service Landscape descreve capacidades, não componentes. Quem o lê como diagrama de implantação sai desenhando um sistema por caixa.

Os "340 microsserviços": o número é ilustrativo, a cena é real. Trocar um monólito por um serviço por Service Domain e descobrir que o custo mudou de lugar: latência de rede entre chamadas, uma pipeline de deploy por serviço e um plantão que não sabe mais onde começar a investigar. Agrupe primeiro, separe por sinal.

Semantic API como contrato de produção: a API semântica define recurso e operação, e para aí. Autenticação, idempotência de retry, formato de erro, paginação e versionamento são decisões suas. Publicar o YAML do BIAN como está é publicar um contrato pela metade.

Mapear para domínio obsoleto: Payment Execution, Payment Order e Payment Instruction não existem mais no BIAN 14. Mapeamento antigo precisa migrar para Payment Order Initiation, Payment Orchestration e os demais domínios novos, senão o heatmap nasce com fantasmas.

Fora do Brasil, o mesmo mapa ajuda a conversar: o T2 do Eurosistema usa ISO 20022 desde março de 2023; PSD3 e PSR foram propostos pela Comissão Europeia em 2023 e seguem em negociação; nos Estados Unidos o FDX é a referência de compartilhamento de dados. O domínio é o mesmo; o regulador e a mensagem mudam.