Full Ddd

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
• Source: lockp111/agent-ddd-engineering
• License: MIT

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