Ddd

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: 
Core domain: 
Supporting domains: 
Generic domains: 
Key stakeholders: 
Known pain points: 

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 — :
| Term | Definition |
|--|--|
|  |  |
|  |  |
|  |  |

LANGUAGE RULES:
- These terms are used in code (class names, method names, variable names)
- These terms are used in conversations with stakeholders
- If a term means different things in different contexts, it belongs in
  different bounded contexts with different definitions
- When a new term emerges, add it to this glossary immediately

Step 3: Event Storming

Facilitate a structured event storming session to discover domain events, commands, aggregates, and boundaries:

Phase 1: Chaotic Exploration (Domain Events)

List every domain event — things that happened in the past tense:

DOMAIN EVENTS (unordered):
🟧 OrderPlaced
🟧 PaymentReceived
🟧 PaymentFailed
🟧 InventoryReserved
🟧 InventoryOutOfStock
🟧 OrderShipped
🟧 OrderDelivered
🟧 OrderCancelled
🟧 RefundIssued
🟧 CustomerRegistered
🟧 PriceChanged
🟧 PromotionApplied

Phase 2: Timeline (Temporal Ordering)

Arrange events in chronological order:

TIMELINE:
CustomerRegistered → OrderPlaced → InventoryReserved → PaymentReceived
  → OrderShipped → OrderDelivered

ALTERNATE FLOWS:
OrderPlaced → InventoryOutOfStock → OrderCancelled → RefundIssued
OrderPlaced → InventoryReserved → PaymentFailed → OrderCancelled
OrderShipped → OrderDelivered → RefundIssued (return)

Phase 3: Commands & Actors

Identify what triggers each event:

COMMANDS AND TRIGGERS:
| Command | Actor | Produces Event |
|--|--|--|
| PlaceOrder | Customer | OrderPlaced |
| ProcessPayment | Payment Gateway | PaymentReceived |
| ReserveInventory | System (auto) | InventoryReserved |
| ShipOrder | Warehouse Staff | OrderShipped |
| CancelOrder | Customer/System | OrderCancelled |
| IssueRefund | Support Agent | RefundIssued |

Phase 4: Aggregates

Group events around the entities that own them:

AGGREGATES:
  > Order
  Commands: PlaceOrder, CancelOrder
  Events: OrderPlaced, OrderCancelled,
  OrderShipped, OrderDelivered
  Invariants:
  - Order total stays > 0
  - Cannot cancel a delivered order
  - Cannot ship without payment

  > Inventory
  Commands: ReserveInventory, ReleaseInventory

Phase 5: Bounded Context Discovery

Draw boundaries around aggregates that share a ubiquitous language:

BOUNDED CONTEXTS (list each with its aggregates and ubiquitous language):
  [ORDERING CONTEXT]
    Aggregates: Order, Cart
    "Order" here means: items a customer wants to buy
  [FULFILLMENT CONTEXT]
    Aggregates: Shipment, Inventory
    "Order" here means: items to pick and ship from warehouse

Step 4: Context Mapping

Define relationships between bounded contexts:

CONTEXT MAP:
  Ordering ──── Partnership ────► Fulfillment
│      │                                │                                │
  Customer/                      Customer/
  Supplier                       Supplier
│      │                                │                                │
  ▼                                ▼
  Billing ──── Conformist ────► Payment Gateway (External)
  Identity ──── Open Host Service ────► All Contexts
  (Published Language)
  Reporting ──── ACL ────► Legacy ERP System

Step 5: Tactical Design — Aggregate Internals

For each aggregate in the core domain, design the internal structure:

AGGREGATE DESIGN — :

Root Entity: 
  ID: 
  State: 
  Invariants:
    1. 
    2. 

Entities (within this aggregate):
  - : 
  - : 

Value Objects:
  - : 

Aggregate Design Rules

AGGREGATE BOUNDARY RULES:
1. CONSISTENCY BOUNDARY: Everything inside an aggregate is immediately
   consistent. Cross-aggregate operations are eventually consistent.

2. TRANSACTION BOUNDARY: One aggregate = one transaction. Never modify
   two aggregates in the same transaction.

3. SIZE RULE: Keep aggregates small. If an aggregate has more than
   3-4 entities, split it.

4. REFERENCE RULE: Aggregates reference each other by ID only, never
   by direct object reference.

5. CASCADE RULE: External code references only the aggregate root.
   Internal entities are accessed through the root.

Step 6: Domain Event Catalog

Document all domain events for cross-context communication:

DOMAIN EVENT CATALOG:
| Event | Source | Payload |
|  | Context |  |
| OrderPlaced | Ordering | orderId, customerId, items[], |
|  |  | totalAmount, placedAt |
| PaymentReceived | Billing | paymentId, orderId, amount, |
|  |  | method, paidAt |
| InventoryReserved | Fulfillment | reservationId, orderId, items[], |
|  |  | warehouseId, reservedAt |
| OrderShipped | Fulfillment | shipmentId, orderId, trackingNo, |

Step 7: Implementation Scaffold

Generate the directory structure and skeleton code:

DIRECTORY STRUCTURE:
src/
├── /
│   ├── domain/
│   │   ├── model/
│   │   │   ├── .ts        # Aggregate root entity
│   │   │   ├── .ts               # Child entities
│   │   │   └── .ts          # Value objects
│   │   ├── events/
│   │   │   └── .ts          # Domain events
│   │   ├── commands/
│   │   │   └── .ts              # Commands
│   │   ├── repositories/
│   │   │   └── .ts           # Repository interface (port)
│   │   └── services/

Step 8: Artifacts & Transition

1. Save domain model: docs/domain/-domain-model.md
2. Save event catalog: docs/domain/event-catalog.md
3. Save context map: docs/domain/context-map.md
4. Save ubiquitous language: docs/domain/ubiquitous-language.md
5. Commit: "ddd: — bounded contexts, aggregates, and event catalog"
6. Suggest next steps:

• "Domain modeled. Run /godmode:architect to select the architecture for this domain."
• "Domain modeled. Run /godmode:plan to decompose aggregate implementation into tasks."
• "Domain modeled. Run /godmode:pattern to select implementation patterns for each aggregate."

Key Behaviors

Never ask to continue. Loop autonomously until done.

# Detect domain model patterns in codebase
grep -rn "class.*Aggregate\|class.*Entity\|class.*ValueObject" src/ --include="*.ts" --include="*.py"
grep -rn "Event\|EventHandler\|DomainEvent" src/ --include="*.ts" --include="*.py" | head -20

IF aggregate has > 4 entities: split into smaller aggregates. WHEN same term means different things in 2 contexts: correct — separate glossary entries. IF domain events > 50: group by context, verify no cross-context coupling.

1. Start with events, not entities. Events reveal behavior.
2. Ubiquitous language non-negotiable. Code = domain language.
3. Bounded contexts are social. Follow team/language boundaries.
4. Aggregates are small. Max 3-4 entities per aggregate.
5. Reference by ID across aggregates. Never direct object refs.
6. Eventual consistency between contexts. Use domain events.
7. Not everything needs DDD. CRUD and reports don't benefit.
8. Event storming is collaborative. Structured thinking catches errors.

On failure: revert with git reset --hard HEAD~1.

Flags & Options

| Flag | Description | |--|--| | (none) | Full DDD session: discovery, event storming, contexts, tactical design | | --strategic | Strategic design only (bounded contexts, context map, ubiquitous language) | | --tactical | Tactical design only (aggregates, entities, value objects, events) |

Quality Targets

• Cross-aggregate refs: 5 consecutive discards.

Source & license

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

• Author: arbazkhan971
• Source: arbazkhan971/godmode
• License: MIT

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