Design Orientado a Domínio

Use esta habilidade quando

• Você precisa modelar um domínio de negócios complexo com limites explícitos.
• Você quer decidir se o DDD completo vale a complexidade adicional.
• Você precisa conectar decisões de design estratégico a padrões de implementação.
• Você está planejando CQRS, event sourcing, sagas ou projeções a partir de necessidades do domínio.

Não use esta habilidade quando

• O problema é CRUD simples com baixa complexidade de negócios.
• Você só precisa de correções de bugs localizadas.
• Não há acesso ao conhecimento do domínio e nenhum especialista de produto proxy.

Instruções

1. Execute uma verificação de viabilidade antes de se comprometer com o DDD completo.
2. Produza artefatos estratégicos primeiro: subdomínios, contextos delimitados, glossário de linguagem.
3. Direcione para habilidades especializadas com base na tarefa atual.
4. Defina critérios de sucesso e evidências para cada etapa.

Verificação de viabilidade

Use DDD completo apenas quando pelo menos duas das seguintes condições forem verdadeiras:

• Regras de negócios são complexas ou mudam rapidamente.
• Múltiplas equipes estão causando colisões de modelo.
• Contratos de integração são instáveis.
• Auditabilidade e invariantes explícitas são críticas.

Mapa de roteamento

• Modelo estratégico e limites: @ddd-strategic-design
• Integrações e tradução entre contextos: @ddd-context-mapping
• Modelagem de código tático: @ddd-tactical-patterns
• Separação de leitura/escrita: @cqrs-implementation
• Histórico de eventos como fonte da verdade: @event-sourcing-architect e @event-store-design
• Fluxos de trabalho de longa duração: @saga-orchestration
• Modelos de leitura: @projection-patterns
• Registro de decisões: @architecture-decision-records

Se modelos forem necessários, abra references/ddd-deliverables.md.

Requisitos de saída

Sempre retorne:

• Escopo e suposições
• Etapa atual (estratégica, tática ou eventada)
• Artefatos explícitos produzidos
• Riscos abertos e recomendação de próximos passos

Exemplos

Use @domain-driven-design to assess if this billing platform should adopt full DDD.
Then route to the right next skill and list artifacts we must produce this week.

Limitações

• Esta habilidade não substitui workshops diretos com especialistas de domínio.
• Ela não fornece geração de código específica de framework.
• Não deve ser usada como justificativa para superengenharia de sistemas simples.