Convert natural language requirements (PRD) into AI-friendly DDD domain design documents in Markdown. Use when the user provides a PRD, requirement doc, or business description and wants a DDD domain model, entity/aggregate design, ER diagram, domain logic placement, or sequence/flow diagrams. Produces structured output that AI agents can directly use for implementation.

Other

Install

openclaw skills install prd-to-ddd-design

PRD to DDD Domain Design

Convert PRD / natural language requirements into a structured DDD design document.

When to Use

User provides a PRD, requirement document, or business description
User asks: "把需求转成DDD设计" / "领域建模" / "domain modeling from requirement"
Before implementation — this is the first step in the AI development workflow

Relationship to Other Skills

design-to-plan: After this skill produces the design doc → split into implementation plans
ddd-domain-model / ddd-cross-layer: Implementation patterns → use after design is finalized

Resources

File	Role	When to Read
This file (SKILL.md)	Map — workflow, phases, output rules	Always (auto-loaded)
phase-guide.md	How-to — analysis heuristics, design criteria, identification rules	When executing each phase
ddd-design-template.md	Template — output section structure with table formats	When writing the design doc

Workflow

PRD / Natural Language
        │
        ▼
  Phase 0 → 1 → 2 → 3 → 4 → 4.5 → 5 → 5.5 → 6
        │
        ▼
  Output: docs/design/<feature>-ddd-design.md

Phase Summary

Phase	Name	What to Produce	Key Input
0	Event Storming	Actor → Command → Aggregate → Event → Policy flow	PRD text
1	Domain Discovery	Ubiquitous language glossary, domain events, business rules	PRD nouns/verbs
2	Strategic Design	Bounded contexts, context mapping	Phase 0-1 results
3	Tactical Design	Entities, VOs, aggregates, relationships	Phase 1-2 results
4	ER Modeling	Mermaid ER diagram (PK/FK only)	Phase 3 entities
4.5	Database Schema	Table mapping, columns, indexes, constraints	Phase 3-4 entities
5	Logic Placement	Entity/VO logic, Gateway/Repo interfaces, Domain Services	Phase 3 + PRD rules
5.5	Cross-Layer Contracts	REST API, Client DTOs, AppService API, Infra adapters	Phase 5 results
6	Behavior Modeling	State machines, sequence diagrams, flowcharts, event flows	Phase 0 + 5

For detailed instructions on each phase (extraction rules, identification heuristics, design criteria), read phase-guide.md.

Execution Steps

Read the PRD document provided by user
Read phase-guide.md for analysis heuristics
Execute phases 0-6 sequentially, using ddd-design-template.md as the output structure
Run the Quality Checklist below before finalizing
Save to docs/design/<feature-name>-ddd-design.md

Output Rules

Pure Markdown with Mermaid diagrams
Chinese for business descriptions, English for technical terms (class names, method signatures)
Align naming and layer placement with ddd-architecture rule
Align domain purity with ddd-domain-layer rule
Every entity must have behaviors (no anemic model)
Every aggregate must list invariants
Every domain logic item must have placement rationale
Database schema must map all entities/VOs to tables with complete columns
Cross-layer contracts must be defined with input/output types

Quality Checklist

Before finalizing the document, verify:

Event Storming & Discovery (Phase 0-1)

All Actors, Commands, Specs, Events, Policies identified
Command → Aggregate → Event mapping is complete
All business nouns mapped to entities or value objects
All business rules captured with rule IDs
Ubiquitous language glossary includes Package column

Tactical Design (Phase 2-3)

Aggregates are small with clear boundaries
No cross-aggregate direct object references (use ID)
Entity behaviors are rich (no anemic model)
State machines documented for stateful entities
Naming follows project DDD conventions

Data & Logic (Phase 4-5)

ER diagram only shows PK/FK, consistent with entity/VO tables
Entity → Table mapping covers all entities and value objects
Table Detail includes all columns with type, nullable, default
Indexes defined for FK columns, frequent queries, unique keys
Domain logic placement has clear rationale for every item
Domain Service design decisions documented with alternatives

Cross-Layer & Behavior (Phase 5.5-6)

REST API endpoints listed with URL, HTTP method, request/response types
Client DTOs (Request/Response) key fields defined
AppService methods listed with Command input and DTO output
Infrastructure adapter-to-gateway mapping is complete
Sequence diagrams cover all core use cases
Flowcharts cover complex branching rules (2+ paths)