# Req Ddd Modeling > Aplicar modelagem DDD estratégica e tática sobre requisitos identificados, produzindo modelo de subdomínios, bounded contexts com cardinalidade, context map, linguagem ubíqua e padrões táticos (entidades, VOs, serviços, eventos de domínio). Usar quando o pedido envolver análise de domínio, mapeamento de subdomínios, definição de bounded contexts ou decisão arquitetural monólito/microserviços. - Skill: `eskcti/req-ddd-modeling` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add eskcti/req-ddd-modeling` - Raw SKILL.md: https://api.skillmd.com/api/skills/eskcti/req-ddd-modeling/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: EskCti (https://skillmd.com/u/eskcti) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/eskcti/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**: | Fonte | Exemplo | |-------|---------| | **Saída do `req-discovery`** | `requirements.md` + `ddd-analysis.md` | | **Descrição livre** | "Sistema de farmácia com produtos, filiais, estoque e vendas" | | **Documento de requisitos** | Qualquer formato textual com requisitos | | **Codebase existente** | Caminho local para análise direta | --- ## 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: | Tipo | Descrição | Exemplo | |------|-----------|---------| | **Core** | Diferencial competitivo — regras únicas do negócio | Vendas, Precificação | | **Supporting** | Suporta o core mas não é diferencial | Estoque, Filiais | | **Generic** | Funcionalidade commodity — pode usar soluções prontas | Autenticação, Notificação, Pagamento | Para cada subdomínio, documentar: ``` ┌──────────────────────────────────────┐ │ Subdomínio: │ │ Tipo: Core | Supporting | Generic │ │ Responsabilidade: │ │ 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:** | Aspecto | Subdomínio | Contexto Delimitado | |---------|-----------|---------------------| | **Natureza** | Parte do negócio | Fronteira de software | | **Foco** | O problema a ser resolvido | A solução em código | | **Origem** | Surge da análise do negócio | Surge do design do sistema | | **Linguagem** | Linguagem do negócio | Linguagem consistente do modelo | | **Papel** | Define **o que** precisa existir | Define **como** isso será implementado | **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: │ │ Subdomínio(s): │ │ Cardinalidade: 1:1 | 1:N | N:1 │ │ Responsabilidade: │ │ Módulo no código: │ └──────────────────────────────────────┘ ``` ### 1.4 — Construir Context Map Mapear as relações entre Bounded Contexts: | Relação | Significado | Diagrama | |---------|-------------|----------| | **Upstream/Downstream** | Um contexto fornece dados ao outro | `A ──▶ B` (A upstream, B downstream) | | **Shared Kernel** | Dois contextos compartilham parte do modelo | `A ◀──▶ B` | | **Conformist** | Downstream adota o modelo do upstream sem adaptação | `A ══▶ B` | | **Anti-Corruption Layer (ACL)** | Downstream traduz o modelo do upstream | `A ──▶ [ACL] ──▶ B` | | **Open Host Service (OHS)** | Upstream expõe API pública estável | `A [OHS] ──▶ B` | | **Published Language** | Comunicação via formato compartilhado (JSON, eventos) | `A ──[PL]──▶ B` | | **Customer/Supplier** | Downstream pode influenciar evolução do upstream | `A ←──▶ B` | | **Separate Ways** | Contextos evoluem independentemente, sem integração | `A B` | 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: ```markdown ### 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 | Padrão | O que é | Quando usar | |--------|---------|-------------| | **Value Object** | Encapsula um valor do domínio e suas regras, garantindo consistência por meio da imutabilidade | Campos com validação (Email, CPF, Money, Name) | | **Entity** | Modela elementos do negócio com identidade própria e comportamento ao longo do tempo | Objetos com ID e ciclo de vida (User, Order, Product) | | **Aggregate** | Cluster de entities/VOs com uma raiz que garante invariantes | Entity raiz que controla filhas (Order → OrderItems) | | **Domain Service** | Encapsula regras de negócio que não pertencem naturalmente a uma única entidade | Cálculos entre entities (PricingPolicy, ShippingCalculator) | | **Domain Event** | Representa fatos importantes que ocorreram no domínio e podem gerar reações no sistema | Ações que disparam consequências (OrderPlaced, PaymentConfirmed) | | **Repository** | Contrato de persistência para aggregates | CRUD de entities raiz | | **Factory** | Criação complexa de aggregates | Quando `Create()` é complexo demais | ### 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: | Elemento | O que descrever | Não fazer | |----------|-----------------|-----------| | Telas / rotas | URL ou nome de screen, persona, ação | Repetir regras de negócio do aggregate | | API consumida | Verbos e paths que a UI chama | Redesenhar contrato sem alinhar ao use case backend | | Guards / menu | Auth, permissões, itens de navegação | — | | Entidades UI | Campos que a tela precisa (DTO espelho) | Tabelas de banco ou entidades EF | | Use cases UI | Login, listar, salvar — orquestram repository HTTP | Lógica de desconto/estoque no Vue | **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: | Critério | Monólito modular | Microserviços | |----------|-----------------|---------------| | Equipe | < 3 devs | > 5 devs com ownership por BC | | Deploy | Cadência única ok | BCs com ritmos de deploy diferentes | | Escala | Carga uniforme | BCs com cargas muito diferentes | | Maturidade | Domínio ainda explorando | Domínio maduro e estável | | Complexidade | Preferir simplicidade | Complexidade gerenciável | **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: | Artefato DDD | Skill TS | Skill KT | Skill CS | |-------------|----------|----------|----------| | Bounded Context (módulo) | `config-new-module` | `config-new-module-kt` | `config-new-module-cs` | | Value Object | `core-value-object` | `core-value-object-kt` | `core-value-object-cs` | | Entity / Aggregate | `core-entity` | `core-entity-kt` | `core-entity-cs` | | Domain Service | `core-domain-service` | `core-domain-service-kt` | `core-domain-service-cs` | | Repository port | `core-repository` | `core-repository-kt` | `core-repository-cs` | | Use Case | `core-use-case` | `core-use-case-kt` | `core-use-case-cs` | | DTO | `core-dto` | `core-dto-kt` | `core-dto-cs` | | Query CQRS | `core-query-cqrs` | `core-query-cqrs-kt` | `core-query-cqrs-cs` | | Persistence adapter | `backend-prisma-data` | `backend-data-kt` | `backend-data-cs` | | Controller | `backend-controller` | `backend-controller-kt` | `backend-controller-cs` | ### 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`: ```markdown ## 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 `/modeling//`: ### `ddd-strategic-model.md` ```markdown # Modelo Estratégico — ## 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` ```markdown # Modelo Tático — ## ### 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) ## (...) ``` ### `ddd-operational-notes.md` ```markdown # Notas Operacionais — ## 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-\"`)" --- ## 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.