effigenix/bin/.claude/skills/ddd-model/SKILL.md

name	description	argument-hint	allowed-tools
ddd-model	Interactive Domain-Driven Design modeling workflow. Use when you need to: design a new domain, identify Aggregates and Entities, choose architecture, define invariants. Generates Go code following Uber Style Guide.	domain-name	Read, Write, Edit, Glob, AskUserQuestion

DDD Domain Modeling Skill

This skill guides you through a complete DDD modeling cycle for Go projects.

Overview

The workflow consists of 6 phases:

1. Domain Discovery - Understand the domain and subdomain type
2. Bounded Contexts - Define context boundaries and ubiquitous language
3. Tactical Modeling - Identify Entities, Value Objects, Aggregates
4. Invariants - Define business rules that must always hold
5. Code Generation - Generate Go code with Clean Architecture
6. Validation - Check DDD rules compliance

Quick Start

When user invokes /ddd-model [domain-name]:

1. Read workflow.md for detailed phase instructions
2. Use AskUserQuestion to gather information at each phase
3. Read templates from templates/ for code generation
4. Apply rules from rules/ for validation
5. Reference examples/banking.md for real-world example

Phase 1: Domain Discovery

Start by understanding the domain:

AskUserQuestion:
- "Describe the domain/subdomain you want to model"
- "What type of subdomain is this?" → Core / Supporting / Generic
- "What are the main business processes?"

Based on subdomain type, determine DDD investment level:

• Core → Full DDD (Aggregates, Domain Events, CQRS if needed)
• Supporting → Simplified DDD (Aggregates, basic patterns)
• Generic → CRUD/Transaction Script (minimal DDD)

Phase 2: Bounded Contexts

Identify and define bounded contexts:

1. List key domain concepts through questions
2. Propose BC boundaries (with ASCII diagram)
3. Define Ubiquitous Language for each BC
4. Map relationships between BCs (Context Map)

Example Context Map:

┌─────────────┐     ┌─────────────┐
│  Accounts   │────>│  Transfers  │
│    (Core)   │     │   (Core)    │
└─────────────┘     └─────────────┘
       │                   │
       v                   v
┌─────────────┐     ┌─────────────┐
│    Fees     │     │   Loyalty   │
│ (Supporting)│     │   (Core)    │
└─────────────┘     └─────────────┘

Phase 3: Tactical Modeling

For each Bounded Context, identify building blocks:

AskUserQuestion for each concept:
- "What has a unique identity?" → Entity
- "What is defined only by its values?" → Value Object
- "What entities always change together?" → Aggregate
- "What is the entry point to the aggregate?" → Aggregate Root

Decision Tree for Entity vs Value Object:

Does it have identity?
├── YES: Does identity matter for equality?
│   ├── YES → Entity
│   └── NO → Value Object with ID field
└── NO: Is it immutable?
    ├── YES → Value Object
    └── NO → Consider making it immutable

Phase 4: Invariants

For each Aggregate, define invariants:

AskUserQuestion:
- "What business rules MUST always be true?"
- "What cannot be violated during changes?"
- "What conditions trigger errors?"

Format invariants as:

// Invariant: Account balance cannot be negative
// Invariant: Transfer amount must be positive
// Invariant: Account must have at least one owner

Phase 5: Code Generation

Generate Go code following Clean Architecture:

1. Read rules/clean-arch.md for folder structure
2. Use templates from templates/:
   • aggregate.go.md - Aggregate Root template
   • entity.go.md - Entity template
   • value-object.go.md - Value Object template
   • repository.go.md - Repository interface template
3. Generate files in:
   • internal/domain/<bc>/ - Domain layer
   • internal/application/<bc>/ - Application layer
   • internal/infrastructure/<bc>/ - Infrastructure layer

Phase 6: Validation

Output validation checklist:

## DDD Validation Checklist

### Aggregate Rules
- [ ] Aggregate Root is the only entry point
- [ ] All changes go through Aggregate Root methods
- [ ] Invariants are checked in constructor and methods
- [ ] No direct references to other Aggregates (only IDs)
- [ ] One Aggregate = one transaction boundary

### Entity Rules
- [ ] ID is immutable after creation
- [ ] Equals/HashCode based on ID only

### Value Object Rules
- [ ] Fully immutable (no setters)
- [ ] Equals compares all fields
- [ ] Validation in constructor

Uber Go Style Guide Conventions

Apply these conventions in generated code:

• Value receivers for Value Objects (immutable)
• Pointer receivers for Aggregates/Entities (mutable)
• Compile-time interface checks: var _ Repository = (*PostgresRepo)(nil)
• Domain-specific error types: type InsufficientFundsError struct{}
• Package names = bounded context names (lowercase)
• Constructor functions: NewAccount(), MustMoney() for tests

File References

• Detailed workflow: workflow.md
• DDD rules checklist: rules/ddd-rules.md
• Clean Architecture guide: rules/clean-arch.md
• Invariants guide: rules/invariants.md
• Code templates: templates/*.go.md
• Example domain: examples/banking.md