# Full Ddd

> Use when starting a new project or module from a PRD, feature spec, or business requirements — even when requirements seem simple. Use when asked to "architect a system from scratch", "turn these requirements into code", "build this feature end-to-end", or when onboarding AI into a codebase lacking DDD structure. Also use when translating whiteboard EventStorming into code. 从零开始, 新项目, 全流程, PRD to…

- **Type:** Skill
- **Install:** `agentstack add skill-lockp111-agent-ddd-engineering-full-ddd`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [lockp111](https://agentstack.voostack.com/s/lockp111)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [lockp111](https://github.com/lockp111)
- **Source:** https://github.com/lockp111/agent-ddd-engineering/tree/main/skills/full-ddd

## Install

```sh
agentstack add skill-lockp111-agent-ddd-engineering-full-ddd
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Running Full DDD Workflow

## Overview

End-to-end DDD pipeline — from raw PRD to production-ready domain code via 7 phases. Phase lifecycle and gates: see Quick Reference below.

**Foundational Principle:** The pipeline is **mandatory for ALL new projects and modules**, regardless of perceived simplicity. Phases 2-6 use the [Ambiguity Handling Protocol](../ddd-protocol/ambiguity-handling-reference.md) (STOP for high-radius ambiguities, ASSUME & RECORD for low-radius ones). There is no complexity threshold below which phases may be skipped. Persistence is mandatory at every phase. Violating the letter of the rules is violating the spirit of the rules.

## When to Use

- When starting a new project or module from a PRD / feature spec, or onboarding AI into a codebase lacking DDD structure.
- **When requirements seem "simple"** — especially then. "Simple" task management has hidden complexity: reassignment, escalation, permissions, notifications.

**Do NOT use when:** iterating on an existing DDD-structured project where artifacts have been archived (use [iterating-ddd](../iterating-ddd/SKILL.md)), fully restructuring an existing non-DDD project to DDD (use [restructuring-ddd](../restructuring-ddd/SKILL.md)), adding features to an existing non-DDD codebase / legacy / 屎山 (use [piloting-ddd](../piloting-ddd/SKILL.md)), importing an existing technical solution document into DDD format (use [importing-technical-solution](../importing-technical-solution/SKILL.md)), modifying logic within an established Bounded Context (use [coding-isolated-domains](../coding-isolated-domains/SKILL.md)), or only adding a cross-context API (use [designing-contracts-first](../designing-contracts-first/SKILL.md) — if context boundaries are not yet defined, start with [mapping-bounded-contexts](../mapping-bounded-contexts/SKILL.md) first).

## Quick Reference

| Step | Action | Output | Gate |
|:---|:---|:---|:---|
| Phase 1 | extracting-domain-events | Domain Events Table | Human approval |
| Exit Gate | Human chooses continue or simplified | — | Human decision |
| Phase 2 | mapping-bounded-contexts | Context Map + Dictionaries | Autonomous (STOP/ASSUME) |
| Phase 3 | designing-contracts-first | Interface Contracts | Autonomous (STOP/ASSUME) |
| Phase 4 | architecting-technical-solution | Technical Solution | Autonomous (STOP/ASSUME) |
| Phase 5 | defining-schemas | Schema files + schema-manifest.md | Autonomous (STOP/ASSUME) |
| Phase 6 | spec-driven-development | Behavior contracts + phase-6-behavior-contracts.md + phase-6/ | Autonomous (STOP/ASSUME) |
| Project Init Gate | Developer: assumptions review + code generators + dependency setup | Confirmed assumptions + compilable project scaffold | Human approval |
| Phase 7 | coding-isolated-domains + test-driven-development | Domain Code + Tests | Human approval |

## Subagent Dispatch I/O

All artifact paths below are relative to `docs/ddd/`. `decisions-log.md` and `assumptions-draft.md` are passed as context to every subagent and omitted from the table for brevity.

| Dispatch Step | Subagent Skill | Input Artifacts | Output Artifacts |
|:---|:---|:---|:---|
| Phase 2 | mapping-bounded-contexts | `phase-1-domain-events.md` | `phase-2-context-map.md`, per-context constraint files, CLAUDE.md DDD section |
| Phase 3 | designing-contracts-first | `phase-1-domain-events.md`, `phase-2-context-map.md` | `phase-3-contracts.md` |
| Phase 4 | architecting-technical-solution | `phase-2-context-map.md`, `phase-3-contracts.md` | `phase-4-technical-solution.md` |
| Phase 5 | defining-schemas | `phase-1-domain-events.md`, `phase-2-context-map.md`, `phase-3-contracts.md`, `phase-4-technical-solution.md` | Schema files + `schema-manifest.md` |
| Phase 6 | spec-driven-development | `phase-1-domain-events.md`, `phase-2-context-map.md`, `phase-3-contracts.md`, `phase-4-technical-solution.md`, schema files (via `schema-manifest.md`) | `phase-6-behavior-contracts.md` + `phase-6/*.md` |
| Phase 7 (per context) | coding-isolated-domains + test-driven-development | `phase-6-behavior-contracts.md`, `phase-6/{context}.md`, schema files (via `schema-manifest.md`) | Domain code + tests, `test-map.md`, `test-coverage.md` |

## Ambiguity Handling

Follow the [Ambiguity Handling Protocol](../ddd-protocol/ambiguity-handling-reference.md) throughout the workflow.

### Orchestrator STOP Triggers

| Ambiguity | Why STOP |
|:---|:---|
| PRD contains contradictory requirements for the same business process | Contradictions cascade into conflicting events, boundaries, and contracts — all downstream phases are invalid |
| Exit Gate decision is unclear — cannot determine if project warrants full pipeline or simplified mode | Wrong mode choice wastes significant effort (full pipeline on trivial project) or produces inadequate artifacts (simplified on complex project) |
| Phase 1 output references external system with undefined integration semantics | Undefined external dependencies create phantom bounded contexts and invalid contracts in Phases 2-3 |
| Project Init Gate reveals assumptions that contradict developer's environment constraints | Phase 7 code built on wrong assumptions requires complete rework |

### Orchestrator ASSUME & RECORD

| Ambiguity | Default assumption |
|:---|:---|
| PRD does not specify sync vs async for a particular interaction | ASSUME sync; record for Phase 3 contract review |
| PRD uses ambiguous domain terminology (could map to multiple concepts) | ASSUME the most common business interpretation; record for Phase 2 UL review |
| No explicit error handling requirements for a business rule | ASSUME standard error-per-invariant pattern; record for Phase 6 review |

In **Autonomous Mode** (Phases 2-6 when orchestrated by `full-ddd`):
- Each phase is dispatched as a per-phase subagent; the orchestrator verifies output before dispatching the next
- Apply STOP/ASSUME protocol at every ambiguity (use tables above for orchestrator-level decisions; sub-skills have their own tables)
- Append ASSUME entries to `docs/ddd/assumptions-draft.md` immediately
- Do NOT wait for per-phase human approval (except at STOP triggers)
- Persist each phase's artifacts immediately upon completion

In **standalone mode** (atomic skills invoked directly without `full-ddd`):
- The atomic skill's own checkpoints remain active
- STOP/ASSUME protocol is still applied

## Session Recovery

**Before starting any phase work**, check for an existing DDD workflow:

1. Check if `docs/ddd/ddd-progress.md` exists.
2. **If it exists:** Read `ddd-progress.md` and ALL persisted phase artifact files (`phase-1-domain-events.md`, `phase-2-context-map.md`, `phase-3-contracts.md`, `phase-4-technical-solution.md`, `schema-manifest.md`, `phase-6-behavior-contracts.md`, `phase-6/*.md`, `test-map.md`, `test-coverage.md`, `assumptions-draft.md`, `decisions-log.md`). Resume from the first incomplete phase. Run `sh skills/full-ddd/scripts/session-recovery.sh` for a quick status report.
3. **If it does not exist:** Create `docs/ddd/` directory and initialize `ddd-progress.md` from the template in `templates/ddd-progress.md`.

**Persisted artifacts contain human-approved decisions and are authoritative.** Do not discard or re-do completed phases unless the user explicitly requests a rollback.

## Implementation (Interactive Orchestration)

**CRITICAL RULE:** You are the orchestrator. **Phase 1** and **Phase 7** use the interactive checkpoint model (present deliverables + wait for explicit approval). **Phases 2-6** run in Autonomous Mode when orchestrated by `full-ddd` (do NOT wait for per-phase approval except at STOP triggers).

**CRITICAL RULE: Sub-Skill Loading.** Before executing any step that delegates to a sub-skill (linked via `[skill-name](path)`), you MUST read the sub-skill's SKILL.md file into your context using the Read tool. The markdown link is a file path — the sub-skill's rules, rationalization table, and red flags are binding constraints for that step. Operating without reading the sub-skill file means operating without anti-hallucination constraints for that step.

### Step 0: Initialization

When starting a new workflow (no `docs/ddd/ddd-progress.md` exists):

1. **Create `docs/ddd/`** directory and initialize `ddd-progress.md` from `templates/ddd-progress.md`.
2. **Enforce platform hooks:** Follow the [Hooks Enforcement Protocol](../ddd-protocol/persistence-defense-reference.md#hooks-enforcement-protocol) — detect platform, set up or merge hooks from templates, update the `Hooks` field in `ddd-progress.md`. **HARD STOP if setup fails.**

### Phase 1 → `extracting-domain-events`
Execute event extraction. Include failure/compensating events. **Checkpoint:** "Does this cover all happy paths AND failure scenarios?"

### Phase 1 Exit Gate (Between Phase 1 and Phase 2)

After Phase 1 is approved AND persisted, present a **Complexity Assessment Summary**:

| Metric | Value |
|:---|:---|
| Total domain events | [count] |
| Failure/compensating events | [count] |
| Distinct actors | [count] |
| Estimated bounded contexts needed | [count] |
| Cross-domain interactions detected | [yes/no, with examples] |
| Business invariants identified | [count] |

Then ask: "Phase 1 is complete. Based on the extracted events, would you like to:
(A) **Continue** the full DDD pipeline (Phase 2: Context Mapping)
(B) **Exit** to simplified mode — skip Phases 2-6, proceed directly to implementation using `coding-isolated-domains`"

**Exit Gate Rules:**
- Agent MUST NOT recommend option B. Present data neutrally.
- Agent MUST NOT add commentary like "this seems simple enough to exit" or "given the low event count, B might be appropriate."
- Only the human may choose B. Agent defaults to A if the response is unclear.
- If human chooses B: update `ddd-progress.md` (workflow_mode: simplified, Exit Gate Result: simplified) + append exit rationale to `decisions-log.md`. Then, before entering `coding-isolated-domains`, present a **Minimal Technical Checklist**: (1) Persistence type? (2) Interface type? (3) Basic error handling strategy? These 3 questions must be answered before coding begins. Append the answers to `docs/ddd/decisions-log.md` under a "Simplified Mode Checklist" entry. **SDD and TDD are not required in simplified mode** — proceed directly to `coding-isolated-domains` after the checklist.
- If human chooses B (simplified mode): STOP/ASSUME protocol still applies during simplified implementation. Record ASSUME entries to `docs/ddd/assumptions-draft.md`. Present the Minimal Technical Checklist before any coding.

Follow the [Per-Phase Subagent Dispatch Protocol](../ddd-protocol/subagent-dispatch-reference.md) for all autonomous phase steps.

### Phase 2 → `mapping-bounded-contexts` (subagent)

Dispatch a subagent with:
- **Sub-skill**: Read [mapping-bounded-contexts](../mapping-bounded-contexts/SKILL.md)
- **Input artifacts**: `docs/ddd/phase-1-domain-events.md`
- **Context**: `docs/ddd/decisions-log.md`, `docs/ddd/assumptions-draft.md`
- **Expected output**: `docs/ddd/phase-2-context-map.md`

Apply [Ambiguity Handling Protocol](../ddd-protocol/ambiguity-handling-reference.md): STOP for context boundary assignments and strategic classification; ASSUME & RECORD for naming and synonym lists. STOP returns to orchestrator for human resolution; ASSUME entries written to `docs/ddd/assumptions-draft.md`.

After subagent returns: verify `docs/ddd/phase-2-context-map.md` exists and has content. Also verify per-context constraint files (`.claude/rules/{context}.md` or platform equivalent) exist and `CLAUDE.md` contains a `## DDD Architecture` section. Then dispatch next phase.

### Phase 3 → `designing-contracts-first` (subagent)

Dispatch a subagent with:
- **Sub-skill**: Read [designing-contracts-first](../designing-contracts-first/SKILL.md)
- **Input artifacts**: `docs/ddd/phase-1-domain-events.md`, `docs/ddd/phase-2-context-map.md`
- **Context**: `docs/ddd/decisions-log.md`, `docs/ddd/assumptions-draft.md`
- **Expected output**: `docs/ddd/phase-3-contracts.md`

Apply [Ambiguity Handling Protocol](../ddd-protocol/ambiguity-handling-reference.md): STOP for data shape, sync/async choice, and error contracts; ASSUME & RECORD for naming and field ordering. Boundary Challenge becomes a subagent self-check (not a human gate) in this mode. STOP returns to orchestrator for human resolution; ASSUME entries written to `docs/ddd/assumptions-draft.md`.

After subagent returns: verify `docs/ddd/phase-3-contracts.md` exists and has content. Then dispatch next phase.

### Phase 4 → `architecting-technical-solution` (subagent)

Dispatch a subagent with:
- **Sub-skill**: Read [architecting-technical-solution](../architecting-technical-solution/SKILL.md)
- **Input artifacts**: `docs/ddd/phase-2-context-map.md` (strategic classification), `docs/ddd/phase-3-contracts.md`
- **Context**: `docs/ddd/decisions-log.md`, `docs/ddd/assumptions-draft.md`
- **Expected output**: `docs/ddd/phase-4-technical-solution.md`

Apply [Ambiguity Handling Protocol](../ddd-protocol/ambiguity-handling-reference.md): STOP for persistence technology, consistency strategy, and interface type; ASSUME & RECORD for library versions and non-critical details. Dimension Challenge becomes a subagent self-check in this mode. STOP returns to orchestrator for human resolution; ASSUME entries written to `docs/ddd/assumptions-draft.md`.

After subagent returns: verify `docs/ddd/phase-4-technical-solution.md` exists and has content. Then dispatch next phase.

### Phase 5 → `defining-schemas` (subagent)

Dispatch a subagent with:
- **Sub-skill**: Read [defining-schemas](../defining-schemas/SKILL.md)
- **Input artifacts**: `docs/ddd/phase-1-domain-events.md`, `docs/ddd/phase-2-context-map.md`, `docs/ddd/phase-3-contracts.md`, `docs/ddd/phase-4-technical-solution.md`
- **Context**: `docs/ddd/decisions-log.md`, `docs/ddd/assumptions-draft.md`
- **Expected output**: Schema files in project directories + `docs/ddd/schema-manifest.md`

Dispatch in Generate mode (or Merge mode if schema files already exist). Apply [Ambiguity Handling Protocol](../ddd-protocol/ambiguity-handling-reference.md): STOP for schema format conflicts, entity relationship design, and event ownership; ASSUME & RECORD for naming conventions and field types. STOP returns to orchestrator for human resolution; ASSUME entries written to `docs/ddd/assumptions-draft.md`.

After subagent returns: verify `docs/ddd/schema-manifest.md` exists and every file listed in the manifest's Schema Inventory table exists on the filesystem. Then dispatch next phase.

### Phase 6 → `spec-driven-development` (subagent)

Dispatch a subagent with:
- **Sub-skill**: Read [spec-driven-development](../spec-driven-development/SKILL.md)
- **Input artifacts**: `docs/ddd/phase-1-domain-events.md`, `docs/ddd/phase-2-context-map.md`, `docs/ddd/phase-3-contracts.md`, `docs/ddd/phase-4-technical-solution.md`, Phase 5 schema files (via `docs/ddd/schema-manifest.md`)
- **Context**: `docs/ddd/decisions-log.md`, `docs/ddd/assumptions-draft.md`
- **Expected output**: `docs/ddd/phase-6-behavior-contracts.md` + `docs/ddd/phase-6/*.md`

Dispatch in Generate mode (or Merge mode if behavior contract files already exist). Apply [Ambiguity Handling Protocol](../ddd-protocol/ambiguity-handling-reference.md): STOP for aggregate state machine ambiguity, schema element ownership, port naming direction, and invariant interpretation; ASSUME & RECORD for event/command naming suffixes, error naming prefix, stateless aggregates, value object ownership, and query-only contexts. STOP returns to orchestrator for human resolution; ASSUME entries written to `docs/ddd/assumptions-draft.md`.

After subagent returns: verify `docs/ddd/phase-6-behavior-contracts.md` exists with Completeness Check, and per-context files exist in `docs/ddd/phase-6/` for every bounded context. Then continue to Project Init Gate.

### Project Init Gate (after Phase 6, before Phase 7)

**MANDATORY human checkpoint before any doma

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [lockp111](https://github.com/lockp111)
- **Source:** [lockp111/agent-ddd-engineering](https://github.com/lockp111/agent-ddd-engineering)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-lockp111-agent-ddd-engineering-full-ddd
- Seller: https://agentstack.voostack.com/s/lockp111
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.