Domain-Driven Design Framework
Framework for tackling software complexity by modeling code around the business domain.
When to Use / When Not to Use
| Use |
Skip |
| Aligning code structure with business concepts |
Architecture layering (use clean-architecture) |
| Defining service boundaries from domain analysis |
Service coupling validation (use service-boundary-validator) |
| Domain experts and developers speak different languages |
Simple CRUD apps without complex business rules |
| Identifying core domain vs. generic subdomains |
|
Process
- Score the model — Rate 0–10 based on the framework below
- Build ubiquitous language — Collaborate with domain experts; document shared terms
- Map bounded contexts — Identify where language changes; draw context boundaries
- Define building blocks — Classify each object as Entity, Value Object, or Aggregate
- Design events and repositories — Wire causality through Domain Events; abstract persistence
- Distill the core domain — Identify what provides competitive advantage; focus effort there
Scoring
Goal: 10/10. A 10/10 means domain experts can read class names and understand them, aggregates are small, and no anemic domain model exists.
Framework
1. Ubiquitous Language
A shared, rigorous language between developers and domain experts used consistently in conversation, documentation, and code.
| Context |
Pattern |
Example |
| Class naming |
Name classes after domain concepts |
LoanApplication, not RequestHandler |
| Method naming |
Use verbs the business uses |
policy.underwrite(), not policy.process() |
| Event naming |
Past-tense domain actions |
ClaimSubmitted, not DataSaved |
| Module structure |
Organize by domain concept |
shipping/, billing/, not controllers/, services/ |
| Code review |
Reject technical-only names |
Flag Manager, Helper, Processor, Utils as naming smells |
See: references/ubiquitous-language.md
2. Bounded Contexts and Context Mapping
A bounded context is an explicit boundary within which a particular domain model is defined and applicable.
| Context |
Pattern |
Example |
| Service integration |
Anti-Corruption Layer |
Translate external API responses into your domain objects at the boundary |
| Team collaboration |
Shared Kernel |
Two teams co-own a small Money value object library |
| Legacy migration |
Conformist / ACL |
Wrap legacy system behind an adapter that speaks your domain language |
| API design |
Open Host Service + Published Language |
Expose a well-documented REST API with a canonical schema |
| Module boundaries |
Separate packages per context |
myapp.shipping and myapp.billing with explicit translation |
See: references/bounded-contexts.md
3. Entities, Value Objects, and Aggregates
- Entity: identity persists across state changes ("same person even if name changes")
- Value Object: defined entirely by attributes; immutable ("$10 bill is interchangeable")
- Aggregate Root: single entry point enforcing consistency; reference other aggregates by ID only
| Context |
Pattern |
Example |
| Identity tracking |
Entity with ID |
Order identified by orderId, survives state changes |
| Immutable attributes |
Value Object |
Address(street, city, zip) — replace, never mutate |
| Consistency boundary |
Aggregate Root |
Order is root; OrderLine items exist only through it |
| Cross-aggregate reference |
Reference by ID |
Order stores customerId, not a Customer object |
See: references/building-blocks.md
4. Domain Events
Domain events capture something that happened in the domain that domain experts care about — named in past tense.
| Context |
Pattern |
Example |
| State transitions |
Raise event on domain action |
order.place() raises OrderPlaced event |
| Cross-context integration |
Publish integration event |
OrderPlaced triggers ShippingLabelRequested in shipping context |
| Audit trail |
Store events as history |
Event log: OrderPlaced → PaymentReceived → OrderShipped |
| Eventual consistency |
Async event handlers |
InventoryReserved handler updates stock asynchronously |
See: references/domain-events.md
5. Repositories and Factories
- Repository: provides the illusion of an in-memory collection; hides persistence details
- Factory: encapsulates complex object creation; ensures aggregates are always created in valid state
| Context |
Pattern |
Example |
| Data access abstraction |
Repository interface |
OrderRepository.findByCustomer(customerId) in domain layer |
| Complex creation |
Factory method |
Order.createFromQuote(quote) validates and assembles |
| Query encapsulation |
Specification |
spec = OverdueBy(days=30); repo.findMatching(spec) |
| Ports and adapters |
Interface in domain, impl in infra |
interface OrderRepository in domain; PostgresOrderRepository in infrastructure |
See: references/repositories-factories.md
6. Strategic Design and Distillation
- Core Domain: competitive advantage; invest best developers and deepest modeling here
- Supporting Subdomain: necessary but not differentiating; build it, don't over-engineer
- Generic Subdomain: commodity; buy or use open-source
| Context |
Pattern |
Example |
| Build vs. buy |
Classify subdomain type |
Build custom pricing engine (core); use Stripe for payments (generic) |
| Code organization |
Separate core from generic |
domain/pricing/ (deep model) vs. infrastructure/email/ (thin adapter) |
See: references/strategic-design.md
Common Mistakes
| Mistake |
Fix |
| Technical names instead of domain language |
Rename to domain terms: ClaimAdjudicator, PolicyUnderwriter |
| One model to rule them all |
Define bounded contexts; each gets its own model |
| Giant aggregates |
Keep aggregates small; reference by ID; accept eventual consistency |
| Anemic domain model (all logic in services) |
Move behavior into entities and value objects |
| No Anti-Corruption Layer at integration points |
Wrap every external system behind a translation layer |
Quick Diagnostic
| Question |
If No |
Action |
| Can a domain expert read your class names? |
Technical jargon instead of domain language |
Rename to ubiquitous language |
| Are bounded context boundaries explicitly defined? |
Models bleed across boundaries |
Draw a context map; define translation strategies |
| Are aggregates small (one root + minimal cluster)? |
Aggregates are large and slow |
Break into smaller aggregates; reference by ID |
| Do domain objects contain behavior? |
Anemic model; logic scattered in services |
Move business rules into entities and value objects |
| Is there an Anti-Corruption Layer at every external integration? |
Foreign models pollute your domain |
Add a translation layer at each boundary |
Output Template
When modeling a domain, provide:
- Bounded context map with context names and relationships
- Ubiquitous language glossary (key terms per context)
- Aggregate definitions with invariants and state transitions
- Domain event list (past tense, with publishers and consumers)
What Claude Does / What You Do
| Claude |
You |
| Drafts bounded context boundaries from domain description |
Validate with domain experts |
| Classifies objects as Entity / Value Object / Aggregate |
Confirm business invariants |
| Generates domain event names and flow |
Review with product team |
| Writes repository interface signatures |
Implement in infrastructure layer |
Reference Files
- ubiquitous-language.md
- bounded-contexts.md
- building-blocks.md
- domain-events.md
- repositories-factories.md
- strategic-design.md
Related Skills
develop:clean-architecture — architecture layers and dependency ruledevelop:event-storming — workshop technique to discover domain events collaborativelydevelop:service-boundary-validator — validate microservice decompositiondevelop:microservices-architect — distributed system design
1---2name: domain-driven-design3description: Use when aligning code structure with business concepts, designing service boundaries, or when domain experts and developers cannot agree on what things mean. Triggers on: "도메인 모델링", "바운디드 컨텍스트", "DDD", "domain-driven design", "bounded context".4license: MIT5---67# Domain-Driven Design Framework89Framework for tackling software complexity by modeling code around the business domain.1011## When to Use / When Not to Use1213| Use | Skip |14|-----|------|15| Aligning code structure with business concepts | Architecture layering (use clean-architecture) |16| Defining service boundaries from domain analysis | Service coupling validation (use service-boundary-validator) |17| Domain experts and developers speak different languages | Simple CRUD apps without complex business rules |18| Identifying core domain vs. generic subdomains | |1920## Process21221. **Score the model** — Rate 0–10 based on the framework below232. **Build ubiquitous language** — Collaborate with domain experts; document shared terms243. **Map bounded contexts** — Identify where language changes; draw context boundaries254. **Define building blocks** — Classify each object as Entity, Value Object, or Aggregate265. **Design events and repositories** — Wire causality through Domain Events; abstract persistence276. **Distill the core domain** — Identify what provides competitive advantage; focus effort there2829## Scoring3031**Goal: 10/10.** A 10/10 means domain experts can read class names and understand them, aggregates are small, and no anemic domain model exists.3233## Framework3435### 1. Ubiquitous Language3637A shared, rigorous language between developers and domain experts used consistently in conversation, documentation, and code.3839| Context | Pattern | Example |40|---------|---------|---------|41| Class naming | Name classes after domain concepts | `LoanApplication`, not `RequestHandler` |42| Method naming | Use verbs the business uses | `policy.underwrite()`, not `policy.process()` |43| Event naming | Past-tense domain actions | `ClaimSubmitted`, not `DataSaved` |44| Module structure | Organize by domain concept | `shipping/`, `billing/`, not `controllers/`, `services/` |45| Code review | Reject technical-only names | Flag `Manager`, `Helper`, `Processor`, `Utils` as naming smells |4647See: [references/ubiquitous-language.md](references/ubiquitous-language.md)4849### 2. Bounded Contexts and Context Mapping5051A bounded context is an explicit boundary within which a particular domain model is defined and applicable.5253| Context | Pattern | Example |54|---------|---------|---------|55| Service integration | Anti-Corruption Layer | Translate external API responses into your domain objects at the boundary |56| Team collaboration | Shared Kernel | Two teams co-own a small `Money` value object library |57| Legacy migration | Conformist / ACL | Wrap legacy system behind an adapter that speaks your domain language |58| API design | Open Host Service + Published Language | Expose a well-documented REST API with a canonical schema |59| Module boundaries | Separate packages per context | `myapp.shipping` and `myapp.billing` with explicit translation |6061See: [references/bounded-contexts.md](references/bounded-contexts.md)6263### 3. Entities, Value Objects, and Aggregates6465- **Entity**: identity persists across state changes ("same person even if name changes")66- **Value Object**: defined entirely by attributes; immutable ("$10 bill is interchangeable")67- **Aggregate Root**: single entry point enforcing consistency; reference other aggregates by ID only6869| Context | Pattern | Example |70|---------|---------|---------|71| Identity tracking | Entity with ID | `Order` identified by `orderId`, survives state changes |72| Immutable attributes | Value Object | `Address(street, city, zip)` — replace, never mutate |73| Consistency boundary | Aggregate Root | `Order` is root; `OrderLine` items exist only through it |74| Cross-aggregate reference | Reference by ID | `Order` stores `customerId`, not a `Customer` object |7576See: [references/building-blocks.md](references/building-blocks.md)7778### 4. Domain Events7980Domain events capture something that happened in the domain that domain experts care about — named in past tense.8182| Context | Pattern | Example |83|---------|---------|---------|84| State transitions | Raise event on domain action | `order.place()` raises `OrderPlaced` event |85| Cross-context integration | Publish integration event | `OrderPlaced` triggers `ShippingLabelRequested` in shipping context |86| Audit trail | Store events as history | Event log: `OrderPlaced` → `PaymentReceived` → `OrderShipped` |87| Eventual consistency | Async event handlers | `InventoryReserved` handler updates stock asynchronously |8889See: [references/domain-events.md](references/domain-events.md)9091### 5. Repositories and Factories9293- **Repository**: provides the illusion of an in-memory collection; hides persistence details94- **Factory**: encapsulates complex object creation; ensures aggregates are always created in valid state9596| Context | Pattern | Example |97|---------|---------|---------|98| Data access abstraction | Repository interface | `OrderRepository.findByCustomer(customerId)` in domain layer |99| Complex creation | Factory method | `Order.createFromQuote(quote)` validates and assembles |100| Query encapsulation | Specification | `spec = OverdueBy(days=30); repo.findMatching(spec)` |101| Ports and adapters | Interface in domain, impl in infra | `interface OrderRepository` in domain; `PostgresOrderRepository` in infrastructure |102103See: [references/repositories-factories.md](references/repositories-factories.md)104105### 6. Strategic Design and Distillation106107- **Core Domain**: competitive advantage; invest best developers and deepest modeling here108- **Supporting Subdomain**: necessary but not differentiating; build it, don't over-engineer109- **Generic Subdomain**: commodity; buy or use open-source110111| Context | Pattern | Example |112|---------|---------|---------|113| Build vs. buy | Classify subdomain type | Build custom pricing engine (core); use Stripe for payments (generic) |114| Code organization | Separate core from generic | `domain/pricing/` (deep model) vs. `infrastructure/email/` (thin adapter) |115116See: [references/strategic-design.md](references/strategic-design.md)117118## Common Mistakes119120| Mistake | Fix |121|---------|-----|122| Technical names instead of domain language | Rename to domain terms: `ClaimAdjudicator`, `PolicyUnderwriter` |123| One model to rule them all | Define bounded contexts; each gets its own model |124| Giant aggregates | Keep aggregates small; reference by ID; accept eventual consistency |125| Anemic domain model (all logic in services) | Move behavior into entities and value objects |126| No Anti-Corruption Layer at integration points | Wrap every external system behind a translation layer |127128## Quick Diagnostic129130| Question | If No | Action |131|----------|-------|--------|132| Can a domain expert read your class names? | Technical jargon instead of domain language | Rename to ubiquitous language |133| Are bounded context boundaries explicitly defined? | Models bleed across boundaries | Draw a context map; define translation strategies |134| Are aggregates small (one root + minimal cluster)? | Aggregates are large and slow | Break into smaller aggregates; reference by ID |135| Do domain objects contain behavior? | Anemic model; logic scattered in services | Move business rules into entities and value objects |136| Is there an Anti-Corruption Layer at every external integration? | Foreign models pollute your domain | Add a translation layer at each boundary |137138## Output Template139140When modeling a domain, provide:1411. Bounded context map with context names and relationships1422. Ubiquitous language glossary (key terms per context)1433. Aggregate definitions with invariants and state transitions1444. Domain event list (past tense, with publishers and consumers)145146## What Claude Does / What You Do147148| Claude | You |149|--------|-----|150| Drafts bounded context boundaries from domain description | Validate with domain experts |151| Classifies objects as Entity / Value Object / Aggregate | Confirm business invariants |152| Generates domain event names and flow | Review with product team |153| Writes repository interface signatures | Implement in infrastructure layer |154155## Reference Files156157- [ubiquitous-language.md](references/ubiquitous-language.md)158- [bounded-contexts.md](references/bounded-contexts.md)159- [building-blocks.md](references/building-blocks.md)160- [domain-events.md](references/domain-events.md)161- [repositories-factories.md](references/repositories-factories.md)162- [strategic-design.md](references/strategic-design.md)163164## Related Skills165166- `develop:clean-architecture` — architecture layers and dependency rule167- `develop:event-storming` — workshop technique to discover domain events collaboratively168- `develop:service-boundary-validator` — validate microservice decomposition169- `develop:microservices-architect` — distributed system design
newkayak12