Bounded Context e limites de domínio

O Bounded Context (BC) é um limite claro, com um Ubiquitous Language único, modelos e invariantes alinhados. Dentro do limite, os termos são inequívocos («Aposta», «Cliente», «Limite»), e fora, o contexto se comunica com os contratos (eventos/comandos) e não leva «caudas» para dentro dos significados alheios. Os limites bem selecionados reduzem a conectividade, facilitam a escala e aceleram a evolução do produto.

1) Porquê os limites

Redução da carga cognitiva. A equipe trabalha com um modelo e uma língua, não com «todo o negócio».
Isolamento dos invariantes. Regras críticas (equilíbrio ≥ 0, login único) vivem no mesmo lugar e são protegidas por agregados.
Gerenciamento de alterações. A evolução do padrão/regulamento dentro do BC não quebra o vizinho - há contratos claros.
Desempenho e confiabilidade. Dentro do BC, você pode escolher um modelo adequado de coerência e armazenamento; lá fora, projeções de asincrona.

2) Como identificar o Bounded Context

1. Event Storing: Subscreva os eventos de domínio «o que aconteceu», depois os comandos «o que você quer que faça» e as unidades «quem garante a regra».

2. Clusters de linguagem: onde palavras e regras coincidem de forma estável é um potencial BC. Onde a palavra «Cliente» significa diferentes (pagador vs jogador) são contextos claramente diferentes.

3. Invariantes e ownership: O que não pode ser quebrado e quem responde? O invariante → para dentro do BC que o pode garantir.

4. Fluxo de valor: Agrupe os passos que muitas vezes mudam juntos - são candidatos para um mesmo BC.

5. Estrutura Org: Se uma parte é feita por um comando separado com um KPI individual - provavelmente é um BC separado (mas não o contrário: a organização não deve ditar cegamente o modelo).

• Disputa de termos («aposta», «bilhete», «round» - significados diferentes).
• O invariante mais quente passa pelos serviços.
• SLO diferente e ritmo de mudança.
• «Dual-write» entre os módulos para ser atômico.

3) Contextos típicos (exemplo de área de objeto)

Identity/KYC - Registro, níveis de verificação, estados de restrição.
Wallet/Ledger - balanços, cabos, reservas, moedas.
Betting/Orders - recepção, cotação, cálculo.
Game/Round - ciclo de vida da rodada, resultados.
Bónus/Promo - cobranças, vaivém, conversão.
Payments - depósitos/conclusões, estatais de passagens de pagamento.
Compliance/Reporting - relatórios, auditorias, vitrines regulatórias.
Catalog/Provider Integration - jogos, versões, estatais de provedores.
Analytics/Read Models - projeções e apresentações materializadas.

4) Context Map: como o BC interage

• Customer–Supplier. Um BC (Suplier) fornece eventos/dados, outro (Customer) ajusta seus modelos.
• Conformist. Customer aceita a linguagem e o modelo Suplier como são (por exemplo, registro regulatório).
• Partnership. Dois BC evoluem sincronicamente linguagem e contratos (muitas vezes, uma equipe/roadmap).
• Shared Kernel. A entrada mínima/biblioteca é compartilhada; usar com cuidado.
• Anti-Corruption Layer (ACL). Camada de proteção que traduz modelos estranhos para a sua língua.
• Open Host Service / Published Language. Protocolos públicos/esquemas, versionáveis e documentados.

Prática: por padrão, use LCA e eventos asinhrônicos; Conformist - apenas se o provedor impõe o padrão, o Shared Kernel é mínimo e consciente.

5) Limite = idioma + modelo + invariantes + armazenamento

• Ubiquitous Language. Dicionário de termos com exemplos.
• Máquinas e invariantes. Quem «mantém» as regras e quais operações são permitidas.
• Modelo de coerência. Strong/COP para dinheiro, EC/causal para vitrines.
• Armazéns e índices. São escolhidos sob invariantes e SLO.
• Contratos de saída. Eventos/comandos, versões de circuitos, SLO de entrega.

Fora: Sem dependências SQL/tabelas diretas. A comunicação é através de um contrato.

6) Limites e coerência (PACELC)

Dentro do BC: selecione o modelo sob invariantes (Wallet - Strong, Betting - Strong na recepção).
Entre BC: Na maioria das vezes, o eventual através de eventos e projeções. Se você precisar de uma verificação sincronizada, é um comando explícito com deadline e falha de indisponibilidade (não «oculto» da chamada REST).

7) Camada anticorrupção (LCA)

O objetivo da LCA é não deixar a língua alheia e os dados «sujos» dentro do BC.

Mapping de padrão: externa ' ' interior '(tipo = Credit, )'.
Validação e enriquecimento: verificação de invariantes, normalização de temporizão, moedas.
Versioning: suporte 'schema _ version' ao contrato externo, compatibilidade invertida.
Idempotidade por 'external _ id '/' operation _ id'.
Observabilidade: marcas de formatação 'fonte', 'schema _ versão', 'maping _ id', DLQ para mensagens 'venenosas'.

8) Limites e dados: posse, projeções, API

Ownership: Quem é dono da «verdade»? Só o dono muda a gravação. O resto do BC são modelos read e links.
Projeções: tabelas sob leitura; atualizam a partir de eventos.
API: comandos (mutados pelo dono) e pesquisas (lendo projeções). Não há updates de dados estranhos.

9) Evolução e versões

Eventos e API - com 'schema _ versão' e política de compatibilidade (aditivo + fallback).
Blue/Green por BC: o novo contrato 'v2' é publicado paralelamente a 'v1', sendo traduzido gradualmente.
Migração: para grandes alterações - nova projeção/serviço, «suingue de duas fases» leitura.

10) Testes de limites

Contract tests: verificar que o BC cumpre o contrato publicado e entende corretamente o contrato de outra pessoa.
Property-based: os invariantes das unidades dentro do BC (balanço, limites, exclusividade).
Chaos em integração: atrasos, out-of-order, duplicados, schema-evolution; a presença de DLQ e uma redrave segura.
Teste NFR: p95/carga de pico de limite (servidor de eventos/LCA).

11) Observabilidade e SLO nos limites

Métricas: throughput eventos/comandos, 'project _ lag _ ms', 'dlq _ rate', erros de mapping, p95 API.
Tracing: tags obrigatórias 'bc', 'tenant _ id', 'event _ id', 'operation _ id', 'schema _ version'.
Alerts: excesso de projeções, aumento das falhas de comandos, «flap» do esquema (muitos «schema _ mismatch»).

12) Multi-tenante e regiões

'tenant _ id' está nas chaves de todos os eventos e projeções na fronteira.
Fairness: limites de publicação/redrave per tenant para que «barulhento» não abale os vizinhos SLO.
Residency: Os dados do BC vivem em uma região «doméstica»; cruzamento regional - unidades/relatórios.

13) Anti-pattern (o que leva ao limite desfocado)

Um «core-service» gigante. Todos no mesmo lugar → luta por transações, lançamentos longos, baixa autonomia.
Integrações de tabela. SELECT direto em tabelas alheias → fragilidade e coupling em esquema.
Dual-write. Ao mesmo tempo, escrever em dois BC «por conveniência» → divergências e sabotagem de invariantes.
Conformist padrão. «Adotaram o modelo alheio como é» → vazamento de significados estranhos, impossibilidade de evolução.
Chamadas sincronizadas ocultas. A chamada de REST «algures dentro», sem contrato explícito e deadline, → uma dependência inesperada de disponibilidade.

14) Exemplo de contornos (padrão verbal)

[Wallet/Ledger] <--CP, Leader, Transactions-->
publishes: WalletReserved/Committed v
[Betting] <--CP on bid taking-->
events: BetPlaced/Settled v
[Read Models/Analytics] <--EC projection-->

[Payments] --ACL--> [Wallet/Ledger]
[Provider Integration] --ACL--> [Game/Round]
[Compliance] <-events - [KYC/Identity], -> reports [Reporting]

15) Mini-hyde para escolha da fronteira

1. Formem os invariantes e identifiquem quem os pode garantir.
2. Descreva o dicionário (10-20 termos) e verifique se o comando tem a mesma compreensão.
3. Desenhe o Context Map e os tipos de relacionamento.
4. Resolva o modelo de coerência dentro e na junção.
5. Projete os contratos (eventos/comandos) e LCA.
6. Pague a observabilidade (métricas/trainees/alertas) e DLQ/redrave.
7. Realize os contracto-testes e «tempestade» (chaos) para as integrações.
8. Verifique a governance: quem domina o idioma/esquema, como as alterações são feitas.

16) Folha de cheque antes de vender

• Cada BC tem um dicionário, aparelhos e invariantes.
• A relação na Context Map foi definida e os contratos foram documentados.
• Integração através de eventos/comandos e LCA, sem dependências SQL diretas.
• Idempotidade de comandos/eventos; há outbox/inbox e DLQ.
• O modelo de coerência (dentro/entre BC) está fixado e testado.
• Versionização de circuitos e estratégia de compatibilidade (v1/v2).
• As métricas de laje/erro/desempenho e alertas estão configuradas.
• As políticas de multi-tenência e data-residency foram cumpridas.
• Playbooks operacionais: schema-mismatch, redrive, rebuild projeções.

17) Receitas rápidas

Dinheiro e limites: um BC separado com CDs e transações, API apenas comandos, eventos como o desfecho da verdade para a leitura.
Fides/diretórios: BC com EC, projeções e dinheiro, explícito 'freshness'.
Integração com provedores externos: sempre via LCA, eventos/comandos, versionização de circuitos.
O crescimento da equipe é de um BC, com um comando, um dono de língua e um guardião de invariantes.
Refactoring monolítico, primeiro contratos e LCA, depois separação física.

Conclusão

Bounded Context não é apenas um gráfico, mas um contrato de trabalho sobre o idioma, as regras e o modo de evolução. Limites claros reduzem a conectividade, aceleram as mudanças e tornam o sistema previsível em operação. Divida por sentido e invariantes, proteja os limites da LCA e dos contratos, mede todas as métricas - e sua arquitetura permanecerá flexível e confiável, mesmo com o rápido crescimento do domínio e do comando.