dddlisted

# DDD — Domain-Driven Design ## Activate When - User invokes `/godmode:ddd` - User says "model the domain", "define bounded contexts", "design aggregates" - User says "event storming", "domain events", "ubiquitous language" - When `/godmode:architect` identifies that domain boundaries need clarification - When `/godmode:pattern` detects an anemic domain model anti-pattern - When business logic complexity outgrows simple CRUD operations - When multiple teams need clear ownership boundaries ## Workflow ### Step 1: Domain Discovery Understand the business domain before modeling: ``` DOMAIN CONTEXT: Business: <what does the business do?> Core domain: <the thing that differentiates this business> Supporting domains: <necessary but not differentiating> Generic domains: <commodity — auth, billing, email> Key stakeholders: <who are the domain experts?> Known pain points: <where does the current model break down?> ``` **Identify the core domain.** This is where you invest the most modeling effort. Generic domains get off-the-shelf solutions. Supporting domains get simple implementations. Only the core domain gets full DDD treatment. ### Step 2: Ubiquitous Language Establish the shared vocabulary between developers and domain experts: ``` UBIQUITOUS LANGUAGE — <Domain Name>: | Term | Definition | |--|--| | <Term 1> | <Precise definition as understood by domain experts | | | AND developers. No ambiguity.> | | <Term 2> | <Definition. Note: "Order" in the Sales context | | | means