Domain-Driven Design Skill

Reference for domain modeling concepts from Eric Evans' "Domain-Driven Design: Tackling Complexity in the Heart of Software."

Activation Triggers

Use this skill when discussing:

•Domain modeling and ubiquitous language
•Bounded contexts and context mapping
•Entities vs value objects
•Aggregates and aggregate roots
•Repository and factory patterns
•Domain events and event storming
•Anti-corruption layers

Quick Reference

Strategic DDD Patterns

Pattern	Purpose	When to Use
Bounded Context	Define clear boundaries	Different teams, different models
Ubiquitous Language	Shared vocabulary	Always within a context
Context Map	Show relationships	Multiple bounded contexts
Anti-Corruption Layer	Protect from external models	Integrating legacy/external systems

Tactical DDD Patterns

Pattern	Characteristics	Identity
Entity	Mutable, lifecycle, identity matters	Has unique ID
Value Object	Immutable, no identity, equality by attributes	No ID needed
Aggregate	Consistency boundary, transactional unit	Has aggregate root
Domain Event	Something that happened, immutable	Named in past tense

Building Blocks

Block	Responsibility
Entity	Model with identity and lifecycle
Value Object	Describe characteristics
Aggregate	Enforce invariants, transactional boundary
Repository	Persist and retrieve aggregates
Factory	Complex object creation
Domain Service	Stateless domain operations
Application Service	Orchestrate use cases
Domain Event	Capture something that happened

Context Mapping Relationships

Relationship	Description
Partnership	Two teams cooperate
Shared Kernel	Shared subset of model
Customer-Supplier	Upstream/downstream dependency
Conformist	Downstream conforms to upstream
Anti-Corruption Layer	Translate between models
Open Host Service	Published API for many consumers
Published Language	Well-documented interchange format
Separate Ways	No integration

Aggregate Design Rules

•Protect invariants - Aggregate root enforces all rules
•Design for consistency - One aggregate per transaction
•Reference by identity - Don't hold direct references to other aggregates
•Use eventual consistency - Between aggregates, not within
•Keep aggregates small - Focused on true invariants

Entity vs Value Object Decision

code

Does identity matter beyond its attributes?
├── YES → Entity (e.g., User, Order, Product)
└── NO → Value Object (e.g., Address, Money, DateRange)

Will instances be shared?
├── YES → Entity (needs identity for references)
└── NO → Value Object (can be replaced/copied)

Directory Structure

code

ddd/
├── SKILL.md
├── strategic/
│   ├── ubiquitous-language.md
│   ├── bounded-contexts.md
│   ├── context-mapping.md
│   └── anti-corruption-layer.md
├── tactical/
│   ├── entities.md
│   ├── value-objects.md
│   ├── aggregates.md
│   ├── domain-services.md
│   └── domain-events.md
├── patterns/
│   ├── repositories.md
│   ├── factories.md
│   └── specifications.md
└── practices/
    ├── event-storming.md
    └── model-exploration.md

Usage Examples

Modeling a Domain

code

Question: "How should I model orders?"

Consider:
1. Define Ubiquitous Language - See strategic/ubiquitous-language.md
2. Identify Entities vs Value Objects - See tactical/
3. Find Aggregates - See tactical/aggregates.md
4. Design Repositories - See patterns/repositories.md

Integrating Systems

code

Question: "How do I integrate with legacy system?"

Consider:
- Define Bounded Context boundary
- Use Anti-Corruption Layer
- Map contexts with Context Map

Based on concepts from "Domain-Driven Design" by Eric Evans.