Quando um sistema cresce, seus conceitos começam a se repetir em diferentes áreas da aplicação. Muitas vezes, a mesma palavra passa a significar coisas distintas dependendo de onde é usada. Essa sobreposição de significados cria modelos confusos, entidades infladas e código difícil de manter.
O Bounded Context surgiu justamente para evitar esse tipo de problema.
Bounded Context?
Um Bounded Context (Contexto Delimitado) é uma fronteira clara onde um conjunto de conceitos, regras e modelos tem um significado único e consistente.
Dentro dessa fronteira:
- as palavras são usadas com precisão;
- o modelo é criado apenas para resolver as necessidades daquele contexto;
- não há obrigação de carregar significados de outros lugares do sistema.
Fora desse limite, os mesmos termos podem ter definições diferentes, e isso é desejável.
Cada contexto descreve apenas a parte do domínio que realmente lhe pertence.
Por que usar Bounded Contexts
A separação do domínio em bounded contexts ajuda a:
- reduzir ambiguidades no significado dos conceitos;
- evitar modelos inflados e genéricos;
- diminuir dependências indevidas entre áreas do sistema;
- permitir que cada parte evolua com clareza e foco.
Essa abordagem torna o software mais compreensível e mais fácil de manter ao longo do tempo.
Vamos a um exemplo simples
Imagine uma plataforma de ensino.
Contexto de catálogo
O objetivo é exibir cursos ao usuário.
O modelo Curso pode conter:
- título
- descrição
- carga horária
- categoria
Esse contexto se preocupa apenas com apresentação.
Contexto de matrículas
Aqui, Curso representa outra realidade:
- quantidade de vagas
- período de matrícula
- regras de elegibilidade
- status da turma
O foco é controlar quem pode se matricular e quando.
É a mesma palavra (Curso), mas com significados diferentes. Cada contexto preserva seu próprio uso do conceito, sem interferências desnecessárias.
Agora segue um exemplo de quando não existe Bounded Context
Sem dividir por contextos, é comum surgir uma única entidade chamada Curso contendo todos os campos de todas as áreas:
- título, descrição e carga horária
- vagas e períodos
- preços
- regras administrativas
- métricas internas
- requisitos e calendários
- status de matrícula
Esse acúmulo cria:
- complexidade desnecessária;
- propriedades que só fazem sentido para parte do sistema;
- validações confusas;
- impacto imprevisível quando a entidade é alterada.
Bounded Context evita justamente essa mistura de significados.
Dúvidas comuns
Uma aplicação deve ter quantos Bounded Contexts?
Não existe uma regra fixa. O domínio é quem define as fronteiras.
Quando há apenas um contexto
Projetos pequenos, MVPs e domínios simples podem começar com um único contexto.
Separar cedo demais traz complexidade artificial.
Quando há vários contextos
Em sistemas reais, é comum existir mais de um.
Isso ocorre quando:
- diferentes áreas do sistema usam o mesmo termo com significados distintos;
- regras de negócio são muito específicas para cada área;
- modelos ficariam grandes demais se unidos.
É natural, e até esperado, que um software maduro tenha múltiplos bounded contexts.
Os bounded contexts precisam ser aplicações separadas?
Não necessariamente. Existem duas formas de organizá-los:
1. Vários bounded contexts na mesma aplicação
Funciona bem quando:
- o sistema ainda não exige escalabilidade independente;
- a equipe é pequena;
- os contextos ainda evoluem juntos.
Nesse caso, a separação é lógica: pastas, módulos, camadas.
2. Cada bounded context como um serviço independente
Acontece quando:
- os contextos são grandes;
- equipes trabalham separadas;
- há necessidade de autonomia e deploy independente.
Isso geralmente aparece em arquiteturas de microsserviços, mas só é recomendado quando existe independência real entre contextos.
E o repositório Git? Monorepo ou Multirepo?
A escolha depende do nível de independência dos bounded contexts.
Monorepo (um único repositório)
Recomendado quando:
- os contextos estão na mesma aplicação;
- mudanças frequentemente envolvem mais de um contexto;
- equipes são pequenas.
Facilita refatoração e manutenção.
Multirepo (um repositório por contexto)
Faz sentido quando:
- cada contexto é um serviço separado;
- equipes diferentes mantêm contextos distintos;
- ciclos de deploy são independentes.
Traz autonomia, mas aumenta a necessidade de contratos estáveis e comunicação clara entre serviços.
Recomendações práticas
- Deixe o domínio apontar onde os contextos começam e terminam.
- Só separe quando existir diferença real de significado ou regras.
- Não transforme cada contexto em um serviço isolado sem necessidade.
- Prefira monorepo para projetos pequenos ou médios.
- Use multirepo apenas quando autonomia e deploy independente forem requisitos do domínio.
Conclusão
O Bounded Context é uma ferramenta essencial para manter sistemas compreensíveis conforme crescem. Ele funciona como um mapa que impede que conceitos se misturem, garantindo que cada parte do domínio tenha seu próprio significado, suas próprias regras e seu próprio ritmo de evolução. Essa clareza reduz atrito entre equipes, diminui ambiguidades e preserva a saúde do modelo ao longo do tempo.
Nem todo software precisa começar com vários bounded contexts. Em sistemas pequenos ou em fases iniciais, um único contexto costuma ser suficiente e até desejável. A divisão se torna realmente importante quando o domínio cresce a ponto de a mesma palavra significar coisas diferentes, quando regras de negócio se tornam complexas em áreas distintas, ou quando o modelo passa a ficar pesado demais para representar tudo de uma só vez.
Quando bem aplicados, os bounded contexts ajudam o software a refletir de forma mais fiel a realidade do negócio, evitando acoplamentos desnecessários e permitindo que cada parte evolua no seu próprio ritmo. Essa prática não é apenas uma escolha arquitetural: é uma maneira de manter o domínio saudável, o código sustentável e a comunicação entre equipes mais clara — três pilares fundamentais em qualquer produto que pretende sobreviver ao tempo e à complexidade inevitável de sistemas vivos.