Quando o modelo de software e o modelo de negócio falam línguas diferentes, cada requisito atravessa uma camada de tradução onde informação se perde. O developer interpreta o que o negócio quer. O negócio recebe o que o developer entendeu. A diferença entre as duas versões acumula como retrabalho, bug de interpretação e feature que tecnicamente funciona mas não resolve o problema que motivou o pedido. Esse custo não aparece em nenhum relatório de sprint. Aparece em velocidade que cai e em reuniões de alinhamento que consomem capacidade sem entregar resultado.
Subcapability 02 de 05 · Software Engineering & Architecture
Domain-Driven Design
Linguagem ubíqua e bounded contexts do Domain-Driven Design que alinham modelo de software ao modelo de negócio e eliminam a camada de tradução onde retrabalho e custo se acumulam.
O que está em jogo
Developer e negócio usam as mesmas palavras com significados diferentes. O que o time comercial chama de "cliente" não é o mesmo que o time financeiro chama de "cliente". Cada reunião de alinhamento repete a mesma discussão. Cada feature entregue exige rodada de ajuste porque o modelo de código não reflete o modelo de negócio. O retrabalho não aparece no relatório. Aparece no lead time que não fecha.
O que é, na prática
Como atuamos
Mapeamento estratégico de domínio
Identificamos subdomínios do negócio, classificamos o que é núcleo diferenciador e o que é suporte genérico, e desenhamos o Context Map que define como cada parte se integra. Essa visão estratégica orienta onde investir rigor de modelagem e onde adotar solução de prateleira.
Linguagem ubíqua compartilhada
Construímos glossário de termos do domínio com definições acordadas entre times técnicos e especialistas de negócio. A linguagem ubíqua é usada no código, nas conversas e nos documentos, eliminando a camada de tradução onde o custo de ambiguidade se acumula.
Bounded contexts com fronteiras explícitas
Definimos onde cada modelo começa e termina, com que dados cada contexto é dono e como contextos se comunicam. Fronteiras explícitas permitem que times evoluam seu domínio sem coordenação constante com outros times.
Event Storming colaborativo
Facilitamos sessões de Event Storming com especialistas de negócio e engenheiros para descobrir eventos de domínio, comandos e agregados sem escrever código. O resultado é compreensão compartilhada antes de qualquer decisão de design.
DDD tático nos bounded contexts críticos
Aplicamos Aggregates, Domain Events e Repositories nos contextos que concentram a lógica de negócio mais complexa e mais sujeita a mudança, com critério econômico. DDD tático tem custo de implementação. Aplicamos onde o retorno justifica.
Ganhos mensuráveis
O que muda no resultado quando essa subcapacidade amadurece.
Retrabalho por requisito mal interpretado
Linguagem ubíqua e bounded contexts com fronteiras claras reduzem a diferença entre o que o negócio pediu e o que o time entregou. O alinhamento acontece na modelagem, antes do código, quando o custo de ajuste é mínimo.
Tempo de onboarding de novo engenheiro no domínio
Glossário de linguagem ubíqua, Context Map documentado e código que reflete os termos do negócio reduzem o período em que o engenheiro novo aprende o domínio por tentativa e erro e por dependência de quem tem o conhecimento implícito.
Impacto de mudança em um contexto sobre outros contextos
Bounded contexts com Anti-Corruption Layers e contratos explícitos contêm o efeito colateral de mudança dentro das fronteiras do contexto. Times mudam seu domínio sem travar coordenação com outros times.
Lead time de mudança em lógica de negócio complexa
Código que reflete diretamente o modelo de negócio reduz o tempo de entendimento antes de qualquer mudança. O engenheiro lê o código e entende o domínio. Sem esse alinhamento, cada mudança começa por reverse engineering do que o código faz versus o que deveria fazer.
Perguntas frequentes
DDD se aplica a qualquer sistema ou só a sistemas complexos?
DDD estratégico, especificamente o mapeamento de bounded contexts e linguagem ubíqua, é útil em qualquer sistema com múltiplos times trabalhando no mesmo produto. DDD tático, com Aggregates, Domain Events e Repositories, tem custo de implementação que se justifica em sistemas com lógica de negócio complexa e sujeita a mudança frequente. Em sistemas simples com poucas regras, o custo de implementação supera o benefício de isolamento.
O que é bounded context na prática?
Bounded context é a fronteira onde um modelo específico é válido e coerente. Dentro do bounded context de vendas, "cliente" tem um conjunto de atributos e regras. Dentro do bounded context de suporte, "cliente" pode ter atributos e comportamentos completamente diferentes. Sem essa fronteira explícita, os dois modelos colidem em uma única estrutura onde cada change request de um time quebra a expectativa do outro.
Como Event Storming ajuda a descobrir o domínio?
Event Storming começa pelos eventos que acontecem no domínio de negócio, escritos em post-its laranja por especialistas de negócio e engenheiros juntos. A partir dos eventos, identifica-se os comandos que os causam, os atores que emitem os comandos e as políticas que conectam eventos a novos comandos. O resultado é uma linha do tempo do domínio que expõe lacunas de entendimento antes de qualquer decisão de arquitetura.
Como o Context Map influencia a arquitetura do sistema?
O Context Map documenta as relações entre bounded contexts e o tipo de integração de cada relação. Uma relação Cliente-Fornecedor tem implicações diferentes de uma relação de Shared Kernel. Anti-Corruption Layer isola um contexto da linguagem e do modelo de outro. Essas decisões de integração determinam o nível de acoplamento real entre times e sistemas, com impacto direto em autonomia de deploy e velocidade de mudança.
Quanto tempo leva para implementar DDD em um sistema existente?
O mapeamento estratégico, Event Storming e identificação de bounded contexts pode ser feito em uma a duas semanas para sistemas de complexidade média. A aplicação de DDD tático em código existente é um processo incremental: cada refatoração de módulo de alta complexidade aplica os padrões onde o retorno é maior. Reescrita total raramente é o caminho. A abordagem de Strangler Fig Pattern isola e substitui módulos progressivamente.
Outras subcapabilities desta capability
Arquitetura Evolutiva
ADRs e fitness functions que registram decisões caras de reverter e validam conformidade automaticamente, mantendo o custo de cada mudança dentro de limites que o negócio consegue absorver.
Clean Architecture & Patterns
Clean Architecture com Dependency Rule que isola regras de negócio de frameworks, banco e UI, reduzindo custo de troca de tecnologia de projeto de seis meses para sprint.
Testing Strategy
Estratégia de testes calibrada por risco, custo e velocidade que substitui pirâmide invertida por distribuição que dá confiança real para mudar e elimina a cerimônia do medo.
Code Quality & Craft
Technical Debt Ratio mensurável e Quality Gates reais que mantêm velocidade de entrega sustentável e impedem que dívida técnica silenciosa vire congelamento de evolução.
Quer clareza sobre onde investir primeiro?
Diagnóstico completo de capacidades de tecnologia com roadmap de evolução conectado ao resultado financeiro.