Context Mapping

Visão Geral

Context mapping é a prática de identificar os bounded contexts de uma organização e o tipo de relacionamento entre eles.

O que torna a técnica valiosa não é o desenho. É que os padrões de relacionamento descrevem poder e dependência entre times, não apenas integração técnica — e nomear isso torna negociável o que antes era implícito.

Problema

Contextos não vivem isolados. Cobrança precisa de dados de subscrição; logística precisa de dados de pedido; um contexto novo precisa consumir um legado que ninguém pode alterar.

Sem mapear esses relacionamentos, três coisas acontecem.

A integração vira ponto a ponto, sem contrato, e o cenário fica invisível.

A assimetria de poder fica implícita: um time descobre que depende de outro que não tem obrigação de atendê-lo, e isso vira conflito recorrente sem nome.

E ninguém sabe onde a tradução deveria acontecer, então ela acontece em todo lugar.

Conceitos Centrais

Os padrões de relacionamento

Evans nomeia vários; estes são os que mais aparecem e os que mais decidem.

Parceria. Dois times com sucesso ou fracasso conjunto. Coordenam releases e evoluem os contratos juntos. Funciona com dois times alinhados; não escala.

Cliente-fornecedor. O fornecedor tem obrigação de atender às necessidades do cliente, negociadas. Requer que o cliente tenha peso organizacional suficiente para que a obrigação seja real.

Conformista. O consumidor adota o modelo do fornecedor sem tradução, porque não tem poder de negociação. Barato e acopla completamente.

Anti-corruption layer. O consumidor traduz o modelo alheio para o seu. Custa manutenção e preserva a independência. Ver anti-corruption layer.

Serviço aberto (open host service) com linguagem publicada. O fornecedor publica um protocolo estável para muitos consumidores. É a resposta quando há consumidores demais para atender individualmente.

Núcleo compartilhado (shared kernel). Dois contextos compartilham deliberadamente uma parte pequena do modelo. Reduz duplicação e acopla os dois times a cada mudança.

Caminhos separados. Nenhuma integração. Duplicar é mais barato que integrar — uma conclusão legítima e raramente considerada.

O padrão reflete organização

A observação que torna a técnica útil:

Padrão	O que ele diz sobre a organização
Parceria	Times com objetivo comum e comunicação direta
Cliente-fornecedor	O consumidor tem peso para negociar
Conformista	O consumidor não tem poder
Anti-corruption layer	O consumidor prefere pagar tradução a se acoplar
Serviço aberto	Consumidores demais para atender um a um
Núcleo compartilhado	Dois times aceitam coordenar

Escolher um padrão que a organização não sustenta não funciona. Declarar cliente-fornecedor quando o fornecedor é outra unidade de negócio sem obrigação produz frustração recorrente — o padrão real é conformista, e nomeá-lo permite decidir se vale construir uma anti-corruption layer.

Upstream e downstream

O contexto a montante influencia o a jusante. A direção da influência importa mais que a direção da chamada de rede.

Um contexto que consome eventos de outro está a jusante, mesmo sem chamá-lo. A mudança de um evento o afeta.

O mapa é para decidir, não para documentar

Um mapa de contextos que só descreve o presente tem pouco valor. Ele serve para perguntar: este padrão é o que queremos? Onde a assimetria está nos custando? O que mudaria se investíssemos numa anti-corruption layer aqui?

Modelo Mental

Para cada par de contextos que se falam, pergunte quem tem obrigação com quem. A resposta dá o padrão, e ela é organizacional.

Quando Usar

• Ao desenhar a integração entre contextos novos.
• Ao entender um cenário existente antes de modificá-lo.
• Quando conflitos recorrentes entre times envolvem dependência técnica.
• Antes de decidir extrair um serviço — o padrão informa o custo.

Quando Não Usar

Num sistema com um contexto. Não há relacionamento a mapear.

Como documento estático. Um mapa desenhado uma vez e arquivado não decide nada.

Para prescrever um padrão que a organização não sustenta.

Como substituto de conversa com os times envolvidos. O mapa é resultado das conversas, não alternativa a elas.

Alternativas

• Diagrama de integração técnica — mostra as conexões e não a relação de poder. Complementar, não substituto.
• Team Topologies — a análise organizacional correspondente. Ver Nível 07.
• Cenário de integração corporativo — o mapa em escala de empresa. Ver Nível 06.

Trade-offs

Os trade-offs são por padrão escolhido:

	Acoplamento	Custo	Independência
Conformista	Máximo	Mínimo	Nenhuma
Núcleo compartilhado	Alto	Coordenação	Parcial
Cliente-fornecedor	Médio	Negociação	Boa
Anti-corruption layer	Baixo	Tradução contínua	Alta
Caminhos separados	Nenhum	Duplicação	Total

Descer na tabela custa mais e compra mais independência. A escolha depende de quanto a independência vale para aquele par.

Modos de Falha

Padrão declarado que a organização não sustenta. O mais comum.

Conformista por omissão. Ninguém decidiu; simplesmente adotou-se o modelo do outro e o acoplamento apareceu depois.

Núcleo compartilhado que cresce. O que deveria ser pequeno vira metade do modelo, e os dois times ficam acoplados em tudo.

Mapa desatualizado. Descreve integrações que mudaram.

Anti-corruption layer que não é mantida. O modelo do fornecedor evolui, a tradução não, e o vazamento volta.

Erros Comuns

Tratar como exercício técnico. É análise organizacional.

Não nomear a assimetria. Deixar implícito que um time depende de outro sem obrigação recíproca produz conflito sem diagnóstico.

Escolher anti-corruption layer para tudo. Custa manutenção; use onde a independência importa.

Não considerar caminhos separados. Duplicar é às vezes a resposta certa.

Exemplo Real

Uma empresa de saúde tinha seis contextos e conflitos recorrentes entre o time de agendamento e o de prontuário.

O sintoma: toda mudança no prontuário quebrava agendamento, e o time de prontuário reagia dizendo que não tinha sido avisado do uso.

O mapeamento revelou que os dois times acreditavam estar em relacionamentos diferentes. Agendamento achava que era cliente-fornecedor — que prontuário tinha obrigação de manter o contrato. Prontuário achava que agendamento era conformista — que consumia por conta e risco.

Nenhum dos dois estava errado sobre o próprio entendimento. Ninguém tinha declarado o padrão.

A conversa que se seguiu foi organizacional, não técnica: prontuário não tinha capacidade de manter compatibilidade com todos os consumidores, e agendamento não tinha peso para exigir.

A decisão foi anti-corruption layer no lado de agendamento, com o custo aceito explicitamente — cerca de duas semanas de construção e manutenção conforme prontuário evoluísse.

Nos dezoito meses seguintes, prontuário mudou o modelo três vezes. Agendamento ajustou a tradução em cada uma, em horas, sem quebrar em produção e sem conflito entre os times.

O que mudou não foi a dependência técnica — ela continua. Foi o padrão ter nome, e o custo ter dono.

Conceitos Relacionados

• Bounded Context — o que se mapeia.
• Anti-Corruption Layer — um dos padrões, em detalhe.
• DDD Estratégico — a síntese.
• Integração — os mecanismos.

Exercício Prático

Liste os pares de contextos ou sistemas que se integram no seu ambiente.

Para cada par, pergunte a alguém de cada lado: qual é a obrigação de um com o outro? Se as respostas divergirem, você encontrou uma fonte de conflito recorrente que não tinha nome.

Perguntas de Entrevista

• Que padrões de relacionamento entre contextos você conhece?
• Por que o padrão reflete a organização e não apenas a técnica?
• Quando "caminhos separados" é a resposta correta?

Para Aprofundar

• Evans, Eric. Domain-Driven Design. Addison-Wesley, 2003 — a parte de design estratégico.
• Vernon, Vaughn. Implementing Domain-Driven Design. Addison-Wesley, 2013.
• Skelton, Matthew; Pais, Manuel. Team Topologies. IT Revolution, 2019.