Domain-Driven Design (DDD) e Agile: a combinação poderosa

DDD (Domain-Driven Design) e Agile não competem — se complementam. DDD resolve o que construir de forma correta; Agile resolve como entregar de forma eficiente.

O que é DDD

DDD é uma abordagem de design de software que:

• Modela o domínio do negócio — entendendo as regras, entidades e processos reais
• Usa linguagem ubiqua — mesma terminologia entre devs e negócio
• Divide em bounded contexts — cada contexto tem seu modelo e responsabilidade

DDD + Agile: por que funcionam juntos

Linguagem Ubiqua + User Stories

User Stories escritas com a linguagem do domínio são mais claras:

Com DDD: “Como comerciante, quero recusar o pedido quando o estoque reservado expira…” Sem DDD: “Como usuário, quero cancelar o pedido quando acabar o estoque…”

A versão com DDD é mais precisa porque usa termos do domínio.

Bounded Contexts + Feature Teams

Cada bounded context pode ser dono de um squad:

Squad Checkout:   contexto "Pagamento"
Squad Catálogo:   contexto "Produto"
Squad Logistics: contexto "Entrega"

Cada squad tem autonomia sobre seu contexto. Dependencies são explícitas (anti-corruption layer entre contextos).

Event Storming + Planning Poker

Event Storming é um workshop onde o time mapeia eventos do domínio:

"Pedido Criado" → "Pagamento Processado" → "Estoque Reservado" → "Item Enviado"

Após o Event Storming, estimar com Planning Poker é natural — cada evento do domínio vira uma ou mais user stories.

Estimativas com DDD

Bounded contexts maduros vs. novos

• Contexto existente: estimativas precisas porque o modelo está claro
• Contexto novo: adicione +30-50% para descobrir o modelo do domínio

Complexidade de integração

“Integrar contexto de Pagamento com contexto de Entrega: 8 pontos” Inclui definir anti-corruption layer, contratos e eventos.

Refatoração do modelo

Se o modelo do domínio está errado (descoberta tardia):

“Refatorar modelo de ‘Cliente’ para separar Pessoa Física de Jurídica: 13 pontos”

DDD em sprints

Sprint	Atividade DDD	Atividade Agile
1	Event Storming do domínio	Refinar histórias baseadas no mapa
2	Definir bounded contexts	Implementar primeiro contexto
3-5	Refinar modelo iterativamente	Entregar features dentro do contexto
6+	Identificar novos contextos	Expandir para próximo contexto

Anti-padrões

DDD em tudo

“Cada feature precisa de agregados, value objects, domain events.” CRUD simples não precisa de DDD. Use para domínios complexos.

DDD sem Agile

“Vamos modelar todo o domínio antes de codificar.” DDD deve evoluir iterativamente, não em Big Design Upfront.

Conclusão

DDD e Agile juntos produzem software que reflete o domínio real do negócio (DDD) entregue de forma incremental e testada (Agile). Use DDD para entender o quê. Use Agile para entregar como.