Bounded Contexts em DDD: Definindo Limites Claros em Microserviços

Um Bounded Context (Contexto Delimitado) é um dos conceitos centrais do Domain-Driven Design, proposto por Eric Evans. Ele representa um limite explícito dentro do qual um modelo de domínio específico é definido e aplicado com consistência.

Em sistemas distribuídos e arquiteturas de microserviços, cada Bounded Context pode ser implementado como um serviço independente, com seu próprio banco de dados, linguagem ubíqua e regras de negócio.

Características Principais

Autonomia: Cada contexto possui suas próprias regras e pode evoluir independentemente. Isso permite que equipes trabalhem sem dependências fortes entre si.

Linguagem Ubíqua: Termos e conceitos têm significado específico dentro do contexto. O que é "Cliente" em Vendas pode ser diferente de "Cliente" em Cobrança.

Consistência Interna: O modelo é consistente apenas dentro dos limites do contexto. Não há necessidade de consistência global entre contextos.

Bounded Contexts vs Microserviços

Embora relacionados, Bounded Contexts e microserviços não são a mesma coisa. Bounded Context é um conceito de design de domínio (estratégico), enquanto microserviço é uma abordagem de arquitetura técnica (tático).

Um Bounded Context pode ser implementado como um ou mais microserviços, dependendo da complexidade e escala. O importante é que o contexto mantenha sua coesão conceitual.

Exemplo Prático: E-commerce

Considere um sistema de e-commerce com os seguintes Bounded Contexts:

Contexto de Vendas: Responsável por gerenciar pedidos, carrinho e checkout. Usa linguagem como Pedido, Item, Carrinho, Cliente. O modelo trata Pedido com status (Pendente, Confirmado, Enviado).

Contexto de Inventário: Controla estoque e disponibilidade. Usa linguagem como Produto, SKU, Quantidade, Lote. O modelo trata Produto com estoque físico e virtual.

Contexto de Pagamento: Processa transações e valida pagamentos. Usa linguagem como Transação, Método de Pagamento, Autorização. Integra com gateway externo.

Context Mapping

DDD define padrões para a interação entre Bounded Contexts:

Customer-Supplier: Um contexto (upstream) define a interface, outro (downstream) consome. Exemplo: Vendas define API, Inventário consome.

Shared Kernel: Dois contextos compartilham um modelo comum. Usar com cautela, pois aumenta acoplamento.

Anti-Corruption Layer (ACL): Uma camada que traduz modelos entre contextos, protegendo a integridade do modelo interno.

Implementação Técnica

A separação física é fundamental: repositórios separados, bancos de dados independentes, deploy independente, times dedicados.

A comunicação entre contextos pode ser feita via REST APIs, mensageria (RabbitMQ, Kafka), gRPC ou Event-Driven Architecture.

Erros Comuns

Bounded Context muito grande: Viola o princípio de responsabilidade única e dificulta manutenção.

Compartilhar banco de dados: Cria acoplamento forte entre contextos e dificulta evolução independente.

Ignorar limites: Um contexto acessar diretamente o modelo de outro quebra o encapsulamento.

Granularidade excessiva: Criar contextos demais gera overhead de comunicação e complexidade operacional.

Conclusão

Bounded Contexts são fundamentais para criar sistemas escaláveis e manuteníveis. Eles permitem que equipes trabalhem de forma autônoma, reduzem acoplamento e facilitam a evolução do sistema.

A chave é identificar corretamente os limites do negócio e aplicar os padrões de Context Mapping adequados para cada situação. Comece com contextos maiores e refine conforme necessário.