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#

FileRoleWhen to Read**This file (SKILL.md)**Map — workflow, phases, output rulesAlways (auto-loaded)phase-guide.mdHow-to — analysis heuristics, design criteria, identification rulesWhen executing each phaseddd-design-template.mdTemplate — output section structure with table formatsWhen writing the design doc

---

Workflow#

text

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

Phase Summary#

PhaseNameWhat to ProduceKey Input0Event StormingActor → Command → Aggregate → Event → Policy flowPRD text1Domain DiscoveryUbiquitous language glossary, domain events, business rulesPRD nouns/verbs2Strategic DesignBounded contexts, context mappingPhase 0-1 results3Tactical DesignEntities, VOs, aggregates, relationshipsPhase 1-2 results4ER ModelingMermaid ER diagram (PK/FK only)Phase 3 entities4.5Database SchemaTable mapping, columns, indexes, constraintsPhase 3-4 entities5Logic PlacementEntity/VO logic, Gateway/Repo interfaces, Domain ServicesPhase 3 + PRD rules5.5Cross-Layer ContractsREST API, Client DTOs, AppService API, Infra adaptersPhase 5 results6Behavior ModelingState machines, sequence diagrams, flowcharts, event flowsPhase 0 + 5

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

---

Execution Steps#

1. Read the PRD document provided by user
2. Read phase-guide.md for analysis heuristics
3. Execute phases 0-6 sequentially, using ddd-design-template.md as the output structure
4. Run the Quality Checklist below before finalizing
5. 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)