Arquitetura Modular, DDD e Bounded Contexts

EAE, bora tomar um cafezinho? ☕

No capítulo anterior, a gente olhou para uma confusão bem comum: achar que arquitetura em camadas e arquitetura modular são a mesma coisa.

Camadas ajudam a organizar o tipo de trabalho que o código faz.

Módulos ajudam a organizar a responsabilidade que o código protege.

Essa diferença parece pequena quando o sistema ainda cabe inteiro na cabeça. Mas, quando o projeto cresce, ela começa a cobrar uma clareza que a pasta service sozinha não consegue entregar.

E foi por isso que eu fechei aquela conversa com uma pergunta que muda bastante o jogo:

qual contexto dá sentido para essa regra?

Agora a gente entra em DDD e bounded contexts.

Mas já vou deixar uma coisa clara antes do café esfriar: DDD não é sinônimo de arquitetura modular.

Também não é pré-requisito obrigatório para todo sistema modular.

E bounded context não é um nome elegante para pasta, pacote, módulo ou microserviço.

DDD entra nessa conversa como uma lente. Uma lente poderosa, principalmente quando o domínio é complexo, cheio de linguagem própria, regras diferentes, significados ambíguos e áreas do negócio que não deveriam ser misturadas sem critério.

A modularidade pergunta:

o que essa divisão protege?

DDD ajuda a fazer outra pergunta junto:

qual modelo de negócio está sendo protegido aqui?

E quando essas duas perguntas começam a conversar, a arquitetura fica bem mais interessante.

Modularidade e DDD não são a mesma coisa

Arquitetura modular é uma forma de organizar o sistema em partes com responsabilidades claras, fronteiras compreensíveis e dependências controladas.

DDD, por outro lado, é uma abordagem para modelar software a partir do domínio do negócio.

As duas coisas se encontram, mas não se anulam.

Eu posso ter uma arquitetura modular sem aplicar DDD de forma profunda.

Posso ter módulos técnicos bem definidos, responsabilidades claras, contratos explícitos, baixo acoplamento e boa separação interna sem necessariamente estar trabalhando com subdomínios, linguagem ubíqua, aggregates, domain services, context maps e toda a caixa de ferramentas do DDD.

Também posso usar termos de DDD em um projeto e ainda assim ter uma arquitetura confusa.

A pasta pode se chamar domain.

O pacote pode se chamar boundedcontext.

A classe pode se chamar AggregateRoot.

E mesmo assim o sistema pode continuar sendo um amontoado de regras espalhadas, dependências circulares e modelos que todo mundo acessa como se fossem patrimônio público.

Nome bonito não segura fronteira.

No máximo, deixa a bagunça com crachá.

A relação saudável é outra: DDD pode fortalecer a modularidade quando ele ajuda a descobrir fronteiras reais do negócio.

Ele não entra para enfeitar a arquitetura.

Entra para melhorar a qualidade das perguntas.

O domínio antes da divisão

Na série inteira, uma ideia vem nos acompanhando:

antes de separar, eu quero entender o motivo da separação.

DDD conversa muito bem com isso.

Porque ele nos obriga a olhar para o domínio antes de sair criando recortes artificiais.

Não é só perguntar:

“quais pastas eu vou criar?”

É perguntar:

“como o negócio fala sobre isso?”

“essa regra pertence a qual área?”

“esse conceito significa a mesma coisa em todos os fluxos?”

“quem é dono dessa decisão?”

“quem muda junto com quem?”

“qual linguagem aparece quando o time de negócio explica o problema?”

Essa é uma mudança importante.

Em uma estrutura puramente técnica, eu posso olhar para o sistema e enxergar controllers, services, repositories, DTOs e entities.

Em uma leitura orientada ao domínio, eu começo a enxergar catálogo, pedido, pagamento, estoque, entrega, cobrança, atendimento, assinatura, autorização, faturamento, comissão, risco, disponibilidade.

Percebe a diferença?

A primeira leitura mostra a natureza técnica dos arquivos.

A segunda mostra as capacidades do negócio.

E arquitetura modular séria precisa dessa segunda leitura.

Não porque tecnologia não importa, mas porque tecnologia sozinha não explica por que aquela parte do sistema existe.

Bounded context não é só uma fronteira física

Um bounded context é, antes de tudo, uma fronteira de significado.

É um espaço onde um modelo faz sentido com uma linguagem própria, regras próprias e decisões próprias.

Essa parte é fácil de repetir e difícil de aplicar.

Porque, na prática, a gente costuma tentar transformar bounded context imediatamente em alguma coisa física:

uma pasta, um módulo, um serviço, um repositório, um deploy, um pacote, um banco separado.

Calma.

Às vezes um bounded context pode virar um módulo.

Às vezes pode virar um conjunto de módulos.

Às vezes pode virar um microserviço.

Às vezes pode continuar dentro de um monólito modular.

Às vezes, no começo, ele pode ser apenas uma fronteira conceitual bem compreendida antes de virar separação física.

O ponto central não é onde ele mora no código no primeiro momento.

O ponto central é qual significado ele protege.

Vamos pensar em um exemplo simples.

A palavra Produto pode aparecer em vários lugares de um sistema.

No catálogo, produto pode ser descrição, imagem, categoria, variações, atributos comerciais e status de publicação.

No estoque, produto pode ser SKU, quantidade disponível, reserva, lote, localização e movimentação.

No pedido, produto pode ser item comprado, preço no momento da compra, desconto aplicado, quantidade e composição do carrinho.

No financeiro, produto pode ser item faturável, código fiscal, tributação e centro de custo.

É a mesma palavra.

Mas não necessariamente é o mesmo modelo.

Se eu tento criar um Product global para atender todos esses contextos, ele começa pequeno e elegante. Depois ganha campo de catálogo. Depois campo de estoque. Depois regra de preço. Depois flag fiscal. Depois lógica de reserva. Depois exceção de marketplace. Depois atributo que só um fluxo usa. Depois alguém cria ProductUtils.

Pronto.

Nasceu aquele objeto que não representa um conceito.

Representa um acordo de paz instável entre partes do sistema que não deveriam estar acopladas daquele jeito.

O bounded context aparece justamente para dizer:

“dentro deste contexto, produto significa isto.”

E fora dele, talvez signifique outra coisa.

Isso não é duplicação ruim por si só.

Às vezes, ter modelos diferentes para a mesma palavra é exatamente o que protege a clareza do sistema.

Linguagem ubíqua como sinal de fronteira

Uma das contribuições mais fortes do DDD é levar a linguagem a sério.

Não como detalhe de nomenclatura.

Como ferramenta de modelagem.

Quando o time de negócio, o time técnico e o sistema usam palavras diferentes para a mesma coisa, a confusão aparece.

Quando usam a mesma palavra para coisas diferentes, a confusão aparece do mesmo jeito, só que mais disfarçada.

É aqui que a linguagem ubíqua ajuda.

Dentro de um contexto, os termos precisam ter significado consistente.

Se o negócio fala “pedido aprovado”, mas o código fala OrderValidated, OrderConfirmed, OrderAccepted e OrderProcessed como se tudo fosse igual, talvez a arquitetura esteja escondendo uma confusão de domínio.

Se “cliente” significa comprador em vendas, titular em cobrança e contato em atendimento, talvez não exista um único Customer capaz de representar tudo sem virar um modelo inchado.

Se “cancelamento” em assinatura não significa a mesma coisa que “cancelamento” em pedido, talvez a regra esteja parecida por nome, mas diferente em comportamento.

O cartógrafo da mesa já começa a puxar o guardanapo.

Porque a linguagem revela fronteira.

Nem sempre de forma perfeita.

Mas revela pistas.

E boas fronteiras normalmente nascem dessas pistas: termos que mudam de significado, regras que variam por área, fluxos que evoluem em ritmos diferentes, decisões que pertencem a donos diferentes.

DDD não manda dividir por qualquer diferença de palavra.

Isso seria exagero.

Mas ele nos ensina a desconfiar quando a mesma palavra carrega sentidos demais.

O módulo como proteção de um modelo

Quando modularidade e DDD trabalham bem juntos, o módulo deixa de ser apenas uma caixa de arquivos.

Ele passa a proteger um modelo.

Isso muda bastante a leitura.

Um módulo de catálogo não deveria ser apenas o lugar onde ficam arquivos relacionados a produto.

Ele deveria proteger as regras e conceitos do catálogo.

Um módulo de pedidos não deveria ser apenas um agrupamento de controllers, services e repositories de pedido.

Ele deveria proteger o ciclo de vida do pedido.

Um módulo de pagamento não deveria ser apenas uma integração com gateway.

Ele deveria proteger a lógica de pagamento que pertence ao sistema, separando o que é regra interna do que é detalhe externo.

Essa diferença parece sutil, mas evita muita arquitetura ornamental.

Porque, se o módulo protege um modelo, eu começo a perguntar:

quais conceitos vivem aqui?

quais regras só fazem sentido aqui dentro?

o que pode ser exposto para fora?

o que deve continuar privado?

quem pode solicitar uma ação e quem não deveria conhecer os detalhes?

esse dado está saindo como contrato ou como vazamento interno?

Percebe como a conversa dos capítulos anteriores continua presente, mas agora com outra profundidade?

Antes falamos de fronteiras, contratos e dependências.

Agora a pergunta é: essas fronteiras estão protegendo apenas arquivos ou estão protegendo sentido?

Nem todo módulo precisa ser um bounded context

Aqui vale um freio importante.

Nem todo módulo é um bounded context.

E nem todo bounded context precisa virar um único módulo.

Um sistema pode ter módulos técnicos que não representam contextos de negócio: observabilidade, autenticação, mensageria, configuração, notificações, auditoria, integração com provedor externo.

Esses módulos podem ser importantes e bem desenhados, mas não necessariamente são bounded contexts no sentido de DDD.

Também pode existir um contexto de negócio grande o suficiente para ser implementado por mais de um módulo interno.

Por exemplo, um contexto de Pedido pode conter módulos internos para criação, pagamento, expedição, cancelamento e histórico, dependendo do tamanho e da complexidade.

O erro está em forçar equivalência.

Quando eu digo que bounded context é sempre um módulo, eu simplifico demais.

Quando digo que módulo nunca tem relação com bounded context, eu perco uma conexão valiosa.

A melhor leitura é mais honesta:

bounded context ajuda a descobrir fronteiras de significado; módulos ajudam a materializar fronteiras de responsabilidade.

Às vezes eles se alinham diretamente.

Às vezes não.

O importante é saber o que estou protegendo.

A tradução entre contextos importa

Se contextos diferentes têm modelos diferentes, eles precisam conversar de algum jeito.

E é aqui que muita arquitetura modular começa a vazar.

Um contexto chama outro e passa seu modelo interno direto.

Outro contexto consome esse modelo e começa a depender dele.

Depois uma mudança interna quebra um fluxo externo.

Depois alguém diz que “foi só alterar um DTO”.

Só que não foi só um DTO.

Foi uma fronteira mal protegida cobrando a conta.

Entre contextos, a conversa deveria acontecer por contratos explícitos.

Não pelo modelo interno de um lado escapando para o outro.

Quando um módulo de pedido precisa saber algo do catálogo, talvez ele não precise conhecer o Product completo do catálogo. Talvez precise apenas de uma visão específica: identificador, nome exibido, preço vigente, disponibilidade ou qualquer informação necessária para aquele caso de uso.

Quando o financeiro precisa registrar um item faturável, talvez ele não deva depender da entidade de produto do catálogo. Ele precisa de um contrato de faturamento.

Quando uma integração externa tem um modelo horroroso, cheio de campos estranhos e nomes que parecem ter sido escolhidos durante uma queda de energia, esse modelo não deveria invadir o domínio interno como se fosse linguagem oficial do sistema.

A tradução protege o modelo.

Pode ser um adapter.

Pode ser uma camada anticorrupção.

Pode ser um mapper específico.

Pode ser um contrato de evento.

A forma varia.

O princípio é o mesmo:

um contexto não deveria engolir o modelo de outro sem mastigar.

E sim, essa frase parece conselho de arquitetura e de almoço ao mesmo tempo.

Mas funciona.

O perigo do modelo global

Muita gente começa tentando criar um modelo central do sistema inteiro.

Um Customer global.

Um Product global.

Um Order global.

Um conjunto de enums globais.

Um pacote common-domain.

Uma pasta shared-model.

A intenção costuma ser boa: evitar duplicação, padronizar conceitos, facilitar reuso.

O problema é que, em domínios complexos, esse modelo global começa a virar um ponto de acoplamento semântico.

Todo mundo depende dele.

Todo mundo quer mudar um pedaço.

Ninguém quer quebrar os outros.

A classe cresce.

Os campos opcionais se multiplicam.

As regras ficam condicionais.

A linguagem perde precisão.

E aquele modelo que deveria representar o domínio começa a representar a dificuldade política de mudar o sistema.

Shared sem dono vira depósito.

E shared de domínio, quando mal pensado, vira depósito com autoridade.

Isso é pior.

Porque agora a bagunça parece arquitetura central.

DDD nos lembra que nem todo conceito compartilhado deveria ser compartilhado como modelo único.

Às vezes, o que precisa ser compartilhado é um contrato.

Às vezes, uma referência.

Às vezes, um identificador.

Às vezes, uma linguagem comum em nível de conversa, mas não uma classe comum em nível de código.

Reuso não é sempre virtude.

Em arquitetura modular, reuso sem critério pode ser só acoplamento vestido para reunião.

Quando DDD fortalece a modularidade

DDD costuma ajudar bastante quando o domínio tem complexidade real.

Quando existem regras que não cabem bem em CRUD simples.

Quando a linguagem do negócio importa.

Quando áreas diferentes usam os mesmos termos com significados diferentes.

Quando o sistema cresce ao redor de capacidades de negócio.

Quando times diferentes evoluem partes diferentes do produto.

Quando mudanças em uma área não deveriam quebrar outra.

Quando a regra de negócio é o centro do valor do software.

Nesses cenários, DDD ajuda a modularidade porque traz critérios mais ricos para definir fronteiras.

A divisão deixa de ser apenas técnica.

Passa a ser conceitual.

O módulo não é só “onde coloco os arquivos de pedido”.

É “onde vive o modelo de pedido que faz sentido para este contexto”.

Isso melhora a conversa entre arquitetura, negócio e código.

E melhora também a capacidade de evolução.

Porque uma mudança em catálogo não precisa automaticamente contaminar pedido.

Uma mudança em estoque não precisa obrigar financeiro a entender detalhes de reserva.

Uma mudança na integração externa não precisa deformar o domínio interno.

Cada contexto ganha mais autonomia.

Não autonomia absoluta.

Mas autonomia suficiente para que a mudança tenha menos efeito dominó.

Quando DDD pode ser peso desnecessário

Agora, cuidado.

DDD também pode ser usado de forma exagerada.

E quando isso acontece, a arquitetura começa a parecer mais sofisticada do que útil.

Se o sistema é pequeno, o domínio é simples, as regras são basicamente cadastro e consulta, a equipe ainda está descobrindo o produto ou a complexidade principal está em entrega rápida, talvez aplicar DDD de forma pesada seja mais custo do que benefício.

Não faz sentido criar um teatro arquitetural inteiro para uma regra que caberia em três linhas bem nomeadas.

Também não faz sentido sair criando aggregate, value object, domain event, factory, specification e domain service só porque o artigo ficou bonito.

Arquitetura não melhora quando troca simplicidade por cerimônia.

Ela melhora quando a estrutura responde melhor ao problema.

DDD é excelente quando ajuda a entender e proteger o domínio.

Mas vira ruído quando é usado para decorar código simples com nomes importantes.

O pragmático da mesa pergunta:

“Tá, mas isso entrega?”

E ele tem razão em perguntar.

Porque uma fronteira só vale o custo se ela protege alguma coisa relevante.

Toda fronteira cobra aluguel.

Se ela não protege regra, mudança, linguagem, autonomia ou clareza, talvez ela seja só parede no meio da sala.

Um exemplo de leitura modular com DDD

Imagine um sistema de e-commerce.

Uma divisão ingênua poderia começar assim:

controllers
services
repositories
entities
dtos

Funciona no começo.

Mas, conforme o sistema cresce, talvez apareçam responsabilidades bem diferentes:

catalog
sales
inventory
payment
shipping
billing
customer-support

Agora a leitura muda.

Dentro de catalog, produto significa algo publicável, descritivo, pesquisável, categorizável.

Dentro de sales, produto aparece como item de venda, com preço aplicado, quantidade, desconto e snapshot do momento da compra.

Dentro de inventory, produto está ligado a SKU, disponibilidade, reserva e movimentação.

Dentro de billing, produto pode aparecer como item faturável.

Não preciso obrigar todos esses contextos a usarem o mesmo modelo.

Posso ter contratos entre eles.

Posso traduzir dados.

Posso manter modelos internos mais precisos.

Posso aceitar alguma duplicação conceitual quando ela protege autonomia.

Essa é uma mudança de maturidade.

O código deixa de perguntar apenas “onde está o service?”.

Ele começa a perguntar “qual contexto é dono desse significado?”.

E essa pergunta evita muita confusão antes que ela vire legado.

A fronteira semântica vem antes da fronteira física

Uma das melhores coisas que DDD oferece para a arquitetura modular é essa noção: primeiro eu entendo a fronteira de significado, depois decido como materializar isso tecnicamente.

Separar fisicamente cedo demais pode ser ruim.

Não separar nunca também pode ser ruim.

O equilíbrio está em observar o domínio.

Se dois conceitos mudam juntos, usam a mesma linguagem, obedecem ao mesmo ciclo de vida e pertencem ao mesmo dono de negócio, talvez façam parte do mesmo contexto.

Se usam a mesma palavra com significados diferentes, mudam por motivos diferentes, têm regras diferentes e donos diferentes, talvez exista uma fronteira pedindo para ser reconhecida.

Essa fronteira pode começar como organização de pacotes.

Pode virar módulo interno.

Pode ganhar contratos mais explícitos.

Pode, em algum momento, virar serviço separado.

Mas essa última parte é conversa para o próximo capítulo.

Por enquanto, o ponto é mais fundamental:

não distribua o que você ainda não entendeu.

Antes de pensar em deploy separado, banco separado, fila, API interna e observabilidade distribuída, eu preciso entender qual fronteira de domínio existe ali.

Microserviço sem contexto claro é só acoplamento remoto com latência.

E ninguém merece pagar rede para descobrir que o problema era modelagem.

Perguntas que ajudam a encontrar bons contextos

Quando eu olho para um sistema tentando aproximar modularidade e DDD, gosto de fazer algumas perguntas simples, mas difíceis de responder bem:

• Essa palavra significa a mesma coisa em todos os lugares?
• Essa regra pertence a qual área do negócio?
• Quem é dono dessa decisão?
• O que muda junto?
• O que muda por motivos diferentes?
• Esse modelo está ficando grande porque é central ou porque está acumulando contextos demais?
• Esse compartilhamento reduz complexidade ou espalha dependência?
• O contrato entre essas partes representa uma intenção clara ou vazou detalhe interno?
• Se eu mudar essa regra, quem deveria ser impactado?
• Se muita gente é impactada, isso é inevitável ou é acoplamento mal resolvido?

Essas perguntas não dão uma resposta automática.

E isso é bom.

Arquitetura séria raramente nasce de resposta automática.

Ela nasce de leitura.

De conversa.

De observar mudança.

De entender linguagem.

De perceber que aquele shared que parecia inocente já está carregando metade do sistema nas costas.

Fechamento

DDD e bounded contexts ajudam a arquitetura modular a enxergar algo que a separação técnica sozinha não mostra com tanta clareza: o significado das fronteiras.

Camadas organizam preocupações técnicas.

Módulos organizam responsabilidades.

DDD ajuda a entender os contextos que dão sentido para essas responsabilidades.

Mas uma coisa não substitui a outra.

DDD não é arquitetura modular com outro nome.

Bounded context não é pasta.

Módulo não é automaticamente contexto.

E contexto não precisa virar microserviço para ser levado a sério.

O valor dessa conversa está em melhorar nossa leitura do sistema.

Quando eu entendo que uma regra só faz sentido dentro de determinado contexto, paro de tratá-la como utilitário genérico.

Quando percebo que a mesma palavra muda de significado em áreas diferentes, paro de forçar um modelo global.

Quando aceito que tradução entre contextos é parte da arquitetura, paro de deixar detalhes internos vazarem como se fossem contratos.

No fundo, a pergunta continua sendo a mesma da série inteira, só que agora com mais precisão:

o que essa divisão protege?

Neste capítulo, a resposta ganhou uma camada nova:

ela pode proteger um modelo, uma linguagem e um contexto de negócio.

E isso importa muito.

Porque sistemas não ficam difíceis apenas porque têm muitos arquivos.

Eles ficam difíceis quando perdem o sentido das próprias fronteiras.

No próximo capítulo, a conversa naturalmente encosta em microserviços.

Mas não do jeito apressado de sempre.

Antes de falar em distribuir sistema, vale lembrar o que ficou na mesa hoje:

se a fronteira conceitual ainda está borrada, separar deploy não resolve.

Só espalha a dúvida pela rede.