Técnicas da segunda-feira e seis realidades
Oito técnicas para usar o mapa no trabalho e como adaptá-las do banco grande à instituição de pagamento.
5 min de leitura
Assista ao documentário desta parte: Parte 2 · Um banco por dentro (~68 min)Na segunda de manhã, o BIAN só vale alguma coisa se ajudar você a tomar uma decisão melhor antes do próximo comitê, da próxima integração ou da próxima migração. A pergunta não é “temos um mapa bonito?”, é “sabemos quem escreve qual registro, qual contrato expõe isso e qual mudança quebra o banco?”.
Oito técnicas, quatro pares
Eu organizo o uso prático do BIAN em quatro pares: mapa, fronteiras, contratos e mudança. Isso evita transformar o Service Landscape 14 em uma parede de nomes.
O primeiro par é mapa. Comece com mapeamento de capacidades: inventarie o que cada sistema faz de verdade, levante Service Domains candidatos, leia a ficha do domínio com o padrão anotado, valide o nome contra a lista da versão fixada e escolha um dono humano por domínio. Sem dono, o mapa morre na primeira reorganização.
Depois vem o heatmap. Use quatro cores: manter, comprar, construir e aposentar. Manter é para o que funciona e não diferencia. Comprar é para commodity com fornecedor maduro. Construir é para onde o banco compete. Aposentar é para o que saiu do negócio ou está duplicado. Cada cor precisa de evidência: incidente, custo de manter ou roadmap. Sem evidência, é opinião pintada.
A lição dura aqui: BIAN não substitui julgamento arquitetural. Ele tira a conversa do achismo e obriga o time a mostrar o registro, o dono e a evidência.
Na prática, eu desconfio de qualquer mapa que não tenha dono humano, evidência por cor e versão explícita do landscape. O desenho pode estar bonito, mas a operação vai cobrar o que ficou implícito.
As oito técnicas em quatro pares
Use o diagrama como roteiro de trabalho: primeiro nomeie capacidades, depois proteja registros, depois feche contratos, depois migre sem apostar tudo em uma virada.
- 1. Capacidades · sistemas reais
- 2. Heatmap · evidência por cor
- 3. Fronteira · dono do registro
- 4. Evento · fato no passado
- 5. Contrato · Semantic API cortada
- 6. Dono e leitor · qualidade no dono
- 7. Estranguladora · cinco camadas
- 8. Fornecedor · cinco perguntas
Fronteira é onde muda o dono do registro
A terceira técnica é simples de dizer e difícil de sustentar: a fronteira passa onde muda o dono do registro. Um time pode cuidar de dois domínios. Dois times nunca escrevem no mesmo registro.
Isso parece detalhe organizacional, mas é arquitetura no nível mais concreto. Se dois sistemas corrigem o mesmo endereço, você não tem integração, tem disputa. A correção deve acontecer no dono do dado. No exemplo desta aula, endereço errado se corrige no Party Reference Data Directory. O leitor pode assinar evento, consultar API e guardar cópia de leitura. Ele não vira dono porque a tela dele encontrou o erro primeiro.
Eventos seguem a mesma disciplina. Eu uso um envelope com quatro itens: nome na forma Domínio.Qualifier.FatoNoPassado, dono, versão do landscape e chave de idempotência. ConsumerLoan.Repayment.Executed é um exemplo de forma: domínio e qualifier oficiais, fato no passado definido pelo autor. A versão pode aparecer como BIAN 14.0.0. A chave de idempotência existe porque o consumidor vai receber o mesmo evento mais de uma vez. O BIAN dá o vocabulário. O envelope é decisão minha.
Técnicas
Contrato pequeno, migração sem salto mortal
A quinta técnica é contrato. Não copie a Semantic API inteira para dentro do seu banco. Parta do caminho da Semantic API, corte o que não usa, adicione autenticação, idempotência, erros e versionamento, e teste por script contra o YAML oficial. O Current Account tem 34 operações. Usar todas só para parecer aderente é trocar precisão por ruído.
A sexta técnica separa dono e leitor do dado. O dono escreve, publica e responde pela qualidade. O leitor assina ou consulta, guarda uma cópia de leitura quando precisa, e manda a correção para o dono. Isso reduz o blast radius de cada mudança porque a fonte de verdade não vira votação entre sistemas.
A sétima técnica é migração estranguladora em cinco camadas: fachada, eventos espelho com nomes v14, leitura nova, escrita nova e desligar. Pular da fachada direto para a escrita nova é onde migrações quebram. A fachada compra tempo, mas não compra consistência.
A oitava técnica é avaliar fornecedor com cinco perguntas por escrito: qual versão do landscape, quais Service Domains cobre e não cobre, quais eventos e APIs usam nomes v14, como os dados saem no fim, e quem paga a atualização de versão do BIAN.
Rotina semanal para não deixar o mapa virar decoração
- 1
Faça as três perguntas em toda decisão
Quem é o dono do registro? Qual é o padrão funcional? Que fato esse dono publica para os vizinhos?
- 2
Leia um domínio inteiro por semana
Leia a ficha e o YAML. O ganho vem do detalhe, não do nome do domínio em uma planilha.
- 3
Valide todo nome novo
Todo Service Domain novo passa pela lista da versão fixada.
Payment Execution,Payment OrderePayment Instructionsão obsoletos na v14. - 4
Escreva uma ADR com fonte
Uma decisão por semana basta, desde que cite a definição usada e a consequência operacional assumida.
Seis realidades e o que fazer na segunda de manhã
| Realidade | Foco de segunda | Leitura arquitetural | Cuidado |
|---|---|---|---|
| Banco grande | Criar vocabulário comum entre dezenas de times e nomear dono por domínio. | Regras de porte importam. O LCR se aplica a ativo total acima de R$ 100 bilhões pela Resolução 4.401. | Sem dono por domínio, o mapa vira glossário sem operação. |
| Banco médio | Escolher onde construir e onde comprar commodity. | Modernização é roteiro plurianual, não mutirão de troca de sistemas. | Construir tudo consome a equipe antes de entregar diferenciação. |
| Fintech | Achar a primeira costura onde o dono já é outro. | O mapa não serve para desenhar trezentos microsserviços. Uma sociedade de crédito direto é instituição financeira pela Resolução CMN 5.050/2022, art. 3º. | Granularidade demais cria operação demais. |
| Cooperativa de crédito | Perguntar se o domínio é da singular ou do sistema. | Pela Lei Complementar 130/2009, há serviços financeiros aos associados por mutualidade. Minha leitura: a parte é associado, a elegibilidade confere a associação, e alguns domínios podem ser compartilhados na central. | Captação e crédito têm restrições aos associados, com ressalvas. Não trate como banco comercial genérico. |
| Instituição de pagamento | Separar modalidade antes de mapear domínio. | A Lei 12.865/2013, art. 6º, § 2º, veda atividades privativas de instituição financeira. O art. 12 trata recursos em conta de pagamento como patrimônio separado. | Pela Resolução BCB 80/2021, o iniciador de transação de pagamento não gerencia conta nem detém fundos. |
| Consultoria e fornecedor | Escrever escopo em Service Domains com versão. | Aceite deve falar em operações e eventos, não em módulo comercial. | Sem cláusula de saída de dados e atualização de versão, o custo aparece no próximo ciclo. |
As seis realidades mudam o uso do mapa
O mesmo BIAN não produz a mesma agenda em toda instituição. Em banco grande, ele reduz tradução entre dezenas de times e força dono por domínio. Em banco médio, ele ajuda a escolher o que construir e o que comprar, porque a equipe não aguenta modernizar tudo ao mesmo tempo.
Em fintech, o mapa não é desculpa para quebrar tudo em microsserviços. Ele mostra a primeira costura onde o dono já é outro. Em cooperativa de crédito, a pergunta operacional é diferente: isto pertence à singular ou ao sistema? Pela Lei Complementar 130/2009, serviços financeiros são prestados aos associados por mutualidade. Minha leitura é tratar a parte como associado, a elegibilidade como conferência de associação, e domínios compartilhados como assunto da central quando o sistema opera junto.
Em instituição de pagamento, a modalidade muda o mapa. Minha leitura: emissor de moeda eletrônica fica perto de um domínio Fulfill de conta; pós-pago fica perto de Credit Card; credenciador vai para Merchant Acquiring Facility; iniciador vai para Payment Order Initiation. Isso é leitura do autor, não fato do BIAN nem da norma.
Para consultoria e fornecedor, escopo bom tem versão, Service Domains, operações, eventos e saída de dados. O resto é conversa que vira aditivo.
O que você deve levar para o trabalho
Payment Order Initiation, Payment Rail, Card Transaction Tracking, Payee Management, Payment Orchestration, Payment Confirmation, Payment Settlement e Customer Consent quando couber.Modalidades da Resolução BCB 80 no mapa (mapeamento do autor)
Toque num cartão para virar.
Perguntas que aparecem quando o mapa encontra a operação
Posso ter dois domínios no mesmo time?
Sim. O problema não é um time cuidar de dois domínios. O problema é dois times escreverem no mesmo registro.
Preciso implementar toda Semantic API?
Não. Parta do caminho oficial, corte o que não usa e adicione os controles que operação cobra: autenticação, idempotência, erros e versionamento.
O mapeamento das modalidades da Resolução BCB 80 é oficial do BIAN?
Não. Nesta aula, esse mapeamento é leitura do autor. Ele serve para raciocinar com precisão, não para fingir que a norma publicou um Service Domain.
Veredito
Use o BIAN na segunda de manhã quando ele amarrar decisão a domínio, registro, contrato e evidência. Se ele virar só catálogo de nomes, pare e volte para a pergunta operacional: quem escreve, quem lê, quem publica, quem paga a mudança e quem responde quando falha.