Req Ddd Modeling

DDD Modeling

Aplicar o Roadmap DDD (Estratégico → Tático → Operacional) sobre requisitos previamente levantados, produzindo um modelo de domínio formal que guia a implementação.

┌──────────────────────────────────────────────────────────────────────────┐
│                     ROADMAP DO DESENVOLVIMENTO                          │
├──────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  ┌────────────────┐  ┌────────────────┐  ┌────────────────┐             │
│  │  ESTRATÉGICO   │  │    TÁTICO      │  │  OPERACIONAL   │             │
│  │                │  │                │  │                │             │
│  │ Compreender o  │  │ Aplicar padrões│  │ Implementar em │             │
│  │ domínio e      │──▶ de modelagem  │──▶ código com     │             │
│  │ organizar em   │  │ para soluções  │  │ frameworks     │             │
│  │ contextos      │  │ consistentes   │  │ sem comprometer│             │
│  │ delimitados    │  │ e sustentáveis │  │ regras de      │             │
│  │                │  │                │  │ negócio        │             │
│  └────────────────┘  └────────────────┘  └────────────────┘             │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘

Este skill é de análise e modelagem, não de implementação. A saída alimenta o req-agile-planning para gerar tasks com referência aos skills de implementação (TS, KT, CS).

Entrada

O skill aceita qualquer uma destas fontes:

Fase 1 — Análise Estratégica

1.1 — Identificar o Domínio

"O domínio de uma aplicação é o conjunto de conhecimentos, regras, conceitos e processos do negócio que o sistema precisa representar e sustentar."

Documentar:

• Nome do domínio (ex.: "PharmaCore — Gestão de Farmácia")
• Propósito principal (o problema que resolve)
• Escopo (o que está dentro e fora do domínio)

1.2 — Identificar Subdomínios

Decompor o domínio em subdomínios classificados por importância:

Para cada subdomínio, documentar:

┌──────────────────────────────────────┐
│ Subdomínio: <nome>                   │
│ Tipo: Core | Supporting | Generic    │
│ Responsabilidade: <descrição>        │
│ Complexidade: Alta | Média | Baixa   │
│ Estratégia: Build | Buy | Outsource  │
└──────────────────────────────────────┘

1.3 — Definir Bounded Contexts

Cada Bounded Context é uma fronteira de software — um limite dentro do qual um modelo de domínio é consistente e a linguagem ubíqua tem significado preciso.

Subdomínio vs Contexto Delimitado:

Cardinalidade Subdomínio ↔ Bounded Context:

Não existe cardinalidade fixa. O mapeamento depende da complexidade:

1:1  Um subdomínio → 1 Bounded Context
     Quando o negócio é coeso e as regras cabem em um único limite.
     Ex.: Subdomínio "Produtos" → BC "Catálogo"

1:N  Um subdomínio → Vários Bounded Contexts
     Quando diferentes partes exigem modelos, regras ou ritmos distintos.
     Ex.: Subdomínio "Vendas" → BC "Pedidos" + BC "Pagamentos" + BC "Entrega"

N:1  Vários subdomínios → 1 Bounded Context
     Quando subdomínios menores compartilham baixa complexidade.
     Ex.: "Configurações" + "Cadastros auxiliares" → BC "Administração"

Para cada Bounded Context:

┌──────────────────────────────────────┐
│ Bounded Context: <nome>              │
│ Subdomínio(s): <lista>               │
│ Cardinalidade: 1:1 | 1:N | N:1      │
│ Responsabilidade: <descrição>        │
│ Módulo no código: <nome do módulo>   │
└──────────────────────────────────────┘

1.4 — Construir Context Map

Mapear as relações entre Bounded Contexts:

Gerar diagrama ASCII:

┌─────────────────────────────────────────────────────────────────┐
│                       CONTEXT MAP                                │
│                                                                   │
│  ┌──────────┐          ┌──────────┐          ┌──────────┐        │
│  │ Catálogo │──[OHS]──▶│ Pedidos  │──[ACL]──▶│ Pagamento│        │
│  │ (Core)   │          │ (Core)   │          │ (Generic)│        │
│  └──────────┘          └────┬─────┘          └──────────┘        │
│                             │                                     │
│                        [Downstream]                               │
│                             │                                     │
│                       ┌─────▼─────┐          ┌──────────┐        │
│                       │  Entrega  │          │   Auth   │        │
│                       │(Supporting)│          │ (Generic)│        │
│                       └───────────┘          └──────────┘        │
│                                                                   │
└─────────────────────────────────────────────────────────────────┘

1.5 — Documentar Linguagem Ubíqua

Para cada Bounded Context, criar glossário de termos:

### Linguagem Ubíqua — BC "Pedidos"

| Termo | Significado neste contexto |
|-------|---------------------------|
| Pedido | Intenção de compra com itens, quantidades e valores |
| Item | Produto + quantidade dentro de um pedido |
| Desconto | Redução percentual ou absoluta aplicada ao total |
| Fechamento | Momento em que o pedido é confirmado e enviado para pagamento |

Importante: o mesmo termo pode ter significados diferentes em BCs distintos. Ex.: "Produto" no Catálogo tem descrição e preço; em Estoque tem lote e quantidade.

Fase 2 — Análise Tática

Para cada Bounded Context, identificar os building blocks (ferramentas táticas) do DDD:

Ferramentas Táticas

Mapeamento por Bounded Context

Para cada BC, produzir:

┌──────────────────────────────────────────────┐
│ Bounded Context: Pedidos                      │
│ Subdomínio: Vendas (Core)                     │
├──────────────────────────────────────────────┤
│                                                │
│ Value Objects:                                 │
│   • Money (valor + moeda + operações)          │
│   • Quantity (inteiro positivo)                 │
│   • OrderStatus (enum: Draft/Placed/Paid/...)  │
│                                                │
│ Entities:                                      │
│   • Order (id, items, total, status, customer)  │
│   • OrderItem (id, product, quantity, price)    │
│                                                │
│ Aggregates:                                    │
│   • Order [raiz] → OrderItem[]                  │
│                                                │
│ Domain Services:                               │
│   • DiscountPolicy (cálculo de desconto)        │
│   • OrderTotalCalculator                        │
│                                                │
│ Domain Events:                                 │
│   • OrderPlaced (quando pedido é confirmado)    │
│   • OrderCancelled (quando pedido é cancelado)  │
│                                                │
│ Repository Ports:                              │
│   • IOrderRepository (save, findById, findAll)  │
│                                                │
│ Superfícies de entrega (para req-agile-planning):│
│   • API REST: Sim — endpoints expostos         │
│   • Web admin: Sim/Não — telas (ver delivery-inventory) │
│   • Mobile: Sim/Não — fluxos app               │
│                                                │
│ Apresentação — Web (se Web = Sim):             │
│   • Rotas/telas, guards, menu                  │
│   • Entidades + use cases de UI (cliente)      │
│                                                │
│ Apresentação — Mobile (se Mobile = Sim):       │
│   • Telas, navegação, estado de tela           │
│   • Entidades + use cases de UI (cliente)      │
│                                                │
└──────────────────────────────────────────────┘

Obrigatório em cada BC do ddd-tactical-model.md:

1. Bloco Superfícies de entrega (API | Web admin | Mobile) — copiar de delivery-inventory.md quando existir.
2. Se Web admin = Sim: seção Apresentação — Web admin (template em references/client-presentation-model.md).
3. Se Mobile = Sim: seção Apresentação — Mobile (mesmo reference).

O domínio canônico (VOs, entities, aggregates) continua no backend; as seções de apresentação não substituem o modelo tático — guiam req-agile-planning e os agents frontend-* / mobile-*.

Fase 2.1 — Modelo de apresentação (cliente)

Quando o BC tiver Web e/ou Mobile = Sim, documentar antes do backlog:

Ordem de leitura: delivery-inventory.md → superfícies no BC → detalhar apresentação → delivery-profile.md → backlog.md com subseções Telas e fluxos por US.

Consultar templates completos: references/client-presentation-model.md.

Fase 3 — Análise Operacional

3.1 — Topologia de Infraestrutura

Monólito e microsserviços dizem respeito à forma como a aplicação é implantada e operada na infraestrutura, não à qualidade da modularização ou da modelagem do negócio.

Recomendar topologia baseada em critérios:

Recomendação padrão: começar com monólito modular (um módulo por BC), migrar para microserviços quando houver evidência concreta de necessidade.

3.2 — Mapeamento para Skills

Cada artefato identificado nas fases anteriores mapeia para um skill de implementação:

3.3 — Análise das 4 Dimensões (Checklist de Viabilidade Holística)

Antes de recomendar a topologia (monólito modular vs microsserviços), avalie brevemente as 4 dimensões para evitar pontos cegos:

1. Organizações e Pessoas

• Quem irá operar e dar manutenção? (Equipe atual / Novos membros / Terceiros)
• A complexidade da solução está adequada à competência da equipe?
• Há necessidade de treinamento, mudança cultural ou gestão de mudança?
• Existe risco de dependência de pessoas-chave (bus factor)?

2. Informação e Tecnologia

• Há riscos de LGPD, segurança de dados ou conformidade regulatória?
• A arquitetura proposta é sustentável com os recursos disponíveis?
• Existem dependências de tecnologias proprietárias ou com custo oculto?
• Como a solução lida com dados sensíveis e auditoria?

3. Parceiros e Fornecedores

• O sistema depende de APIs externas, serviços gratuitos (ex: Google/Microsoft Nonprofit) ou gateways de pagamento?
• Qual o SLA e o plano de contingência se o fornecedor cair ou mudar as regras?
• Existe risco de dependência excessiva de um único fornecedor?
• Como a solução lida com integrações de terceiros (contratos, custos, riscos)?

4. Fluxos de Valor e Processos

• Esta funcionalidade elimina um gargalo real ou apenas o digitaliza (criando um "gargalo digital")?
• O fluxo de valor ponta a ponta foi mapeado e otimizado antes da automação?
• Existem etapas manuais que deveriam ser automatizadas (ou vice-versa)?
• Como a solução impacta a experiência do usuário final e a cocriação de valor?

Saída da Análise

Gere um bloco resumido no arquivo ddd-operational-notes.md:

## Análise das 4 Dimensões

### Riscos e Recomendações

**Pessoas:** [Ex: Equipe de 2 pessoas pode ter dificuldade com microsserviços. Recomendação: começar com monólito modular.]

**Tecnologia:** [Ex: Dependência de API gratuita do Google. Risco: mudança de regras sem aviso. Mitigação: criar camada de abstração.]

**Parceiros:** [Ex: Gateway de pagamento com SLA de 99,5%. Risco: indisponibilidade impacta receita. Mitigação: ter fornecedor alternativo.]

**Processos:** [Ex: Fluxo de aprovação manual pode virar gargalo. Recomendação: automatizar notificações e alçadas.]

---

## Saída

Gerar os seguintes documentos em `<docsPath>/modeling/<project-name>/`:

### `ddd-strategic-model.md`

```markdown
# Modelo Estratégico — <Nome do Projeto>

## Domínio
(nome, propósito, escopo)

## Subdomínios
(tabela com tipo, responsabilidade, complexidade, estratégia)

## Bounded Contexts
(tabela com subdomínio(s), cardinalidade, responsabilidade, módulo)

## Context Map
(diagrama ASCII com relações tipadas)

## Linguagem Ubíqua
(glossário por Bounded Context)

ddd-tactical-model.md

# Modelo Tático — <Nome do Projeto>

## <Bounded Context 1>

### Domínio (backend)
(VOs, Entities, Aggregates, Domain Services, Domain Events, Repository ports)

### Superfícies de entrega
| API REST | Web admin | Mobile |
|----------|-----------|--------|
| Sim      | Sim       | Não    |

### Apresentação — Web admin
(se Web = Sim: tabelas de telas/rotas, navegação, entidades UI, use cases UI — ver references/client-presentation-model.md)

### Apresentação — Mobile
(se Mobile = Sim: idem para app)

## <Bounded Context 2>
(...)

ddd-operational-notes.md

# Notas Operacionais — <Nome do Projeto>

## Topologia Recomendada
(monólito modular ou microserviços + justificativa)

## Mapeamento BC → Módulo
(tabela BC → módulo no código → skill de scaffold)

## Prioridade de Implementação
(quais BCs implementar primeiro, baseado em subdomínio Core)

Integração com Outros Skills

Pipeline completo

Sistema fonte            req-discovery         req-ddd-modeling          req-migration-strategy   delivery-profile.md      req-agile-planning
(qualquer linguagem) →   (leitura) →           (modelagem DDD) →        [opcional]         →   (stack+superfícies) →    (backlog full-stack)
                         requirements.md       ddd-strategic-model.md   migration-strategy.md  planning/*/              backlog.md
                         delivery-inventory.md ddd-tactical-model.md    acl-design.md          delivery-profile.md      + frontend/mobile tasks
                         ddd-analysis.md       (+ superfícies/BC)                                epics-summary.md

O req-ddd-modeling pode ser usado diretamente sem req-discovery — basta fornecer uma descrição do domínio.

Depois (consumidores):

• req-migration-strategy → se o sistema for legado em produção
• req-agile-planning → usa o modelo DDD para gerar épicos (1 por BC), stories e tasks (EP-000 com docker/cicd)
• config-project-fullstack → orquestra bootstrap completo
• openspec-propose → proposta de change para bootstrap ou BC específico

Ofereça essas opções ao finalizar:

"Modelagem DDD concluída!\n> Próximos passos:\n> 1. [Se legado] Estratégia de migração (req-migration-strategy)\n> 2. Definir perfil de entrega (delivery-profile.md) — stack + API/Web/Mobile por BC\n> 3. Gerar backlog (req-agile-planning) — cada US com web/mobile: subseções Telas e fluxos + tasks inside-out (não só API)\n> 4. Bootstrap (config-project-fullstack + OpenSpec)\n> 5. Implementar BC (openspec-propose \"ep-XXX-<bc>\")"

Guardrails

• Não invente subdomínios — baseie-se nos requisitos observados
• Prefira 1:1 (subdomínio → BC) como default; 1:N ou N:1 apenas com justificativa
• Comece com monólito modular — só recomende microserviços com evidência
• Documente a linguagem ubíqua — termos devem ser acordados, não assumidos
• Domain Events são opcionais — só incluir quando há reações cross-context claras
• Não misture camadas — Entities no Domain, Use Cases na Application, never vice-versa
• Inclua superfícies de entrega por BC — sem coluna Web/Mobile o backlog ficará incompleto
• Inclua modelo de apresentação quando Web ou Mobile = Sim — sem rotas/telas/use cases UI o req-agile-planning gera só interface:page
• Não duplique o aggregate no cliente — entidades UI são projeção/DTO; regras de negócio ficam no backend

References

• Consultar references/ddd-strategic-patterns.md para padrões estratégicos detalhados.
• Consultar references/ddd-tactical-patterns.md para padrões táticos detalhados.
• Consultar references/client-presentation-model.md para templates web/mobile por BC.

Global Standards

• Consultar ../skills-standards.md para padrões globais de nomenclatura e convenções gerais entre skills.

References

Templates de Análise de Requisitos (Luiza Silva)

Consultar ../references/templates-luiza-silva.md para os formatos exatos dos seguintes templates:

• T03: Ficha Individual de Requisito → Usar para detalhar entidades, aggregates ou comportamentos complexos identificados durante a modelagem tática.
• T05: Registro de Regra de Negócio → Usar para documentar invariantes de domínio, políticas e regras que influenciam o comportamento das entidades e aggregates.
• T06: Registro de Decisões → Usar SEMPRE que houver escolha arquitetural (ex: monólito vs microsserviços, cardinalidade de Bounded Contexts, padrão de integração como ACL/OHS).
• T07: Registro de Dúvidas e Pendências → Usar para controlar lacunas na modelagem, dependências não mapeadas ou validações pendentes com stakeholders de domínio.

Instruções de Uso

Ao gerar documentação de saída (ddd-strategic-model.md, ddd-tactical-model.md, ddd-operational-notes.md):

1. Utilize o formato T03 para requisitos complexos que impactam a modelagem de domínio.
2. Utilize o formato T05 para cada regra de negócio ou invariante de domínio identificado.
3. Utilize o formato T06 para toda decisão arquitetural relevante (topologia, cardinalidade, padrões de integração).
4. Utilize o formato T07 para toda dúvida ou pendência que impeça a conclusão da modelagem.

Regra Prática

Decisões sem registro viram rediscussões. Sempre que houver escolha entre alternativas, registre a decisão, a motivação e os impactos usando o template T06.