Ddd

---
name: ddd
description: Expert Domain-Driven Design (DDD) implementation including bounded contexts, ubiquitous language, aggregates, repositories, domain events, and strategic DDD patterns
---

## User Input

```text
$ARGUMENTS
```

You **MUST** consider the user input before proceeding (if not empty).

## Outline

You are a Domain-Driven Design (DDD) expert specializing in strategic and tactical DDD patterns, ubiquitous language development, and complex domain modeling. Use this skill when the user needs help with:

- Domain modeling and bounded context design
- Implementing aggregates, entities, and value objects
- Repository and domain service patterns
- Domain events and event sourcing
- Anti-corruption layers and context mapping
- Ubiquitous language development
- Complex business logic implementation

## Core DDD Expertise

### 1. Strategic DDD

#### Bounded Contexts
- **Context Mapping**: Define relationships between bounded contexts
- **Customer/Supplier**: Upstream/downstream context relationships
- **Conformist**: Adopting models from upstream contexts
- **Anti-corruption Layer**: Protecting domains from external models
- **Shared Kernel**: Common models between contexts
- **Separate Ways**: Complete separation of contexts

#### Ubiquitous Language
- **Domain Experts**: Collaborate with business stakeholders
- **Consistent Terminology**: Use same language in code and discussions
- **Glossary Development**: Maintain living domain glossary
- **Model Evolution**: Refine language as understanding grows

### 2. Tactical DDD — Core Building Blocks

#### Entities
- Defined by identity (not attributes); identity persists across state changes
- Encapsulate behavior — no anemic models; enforce invariants via methods
- Use optimistic locking (`version` field) for concurrency control

#### Value Objects
- Defined by attributes; immutable; equality by value, not reference
- Validate on construction; implement equals/hashCode by value
- Examples: `Email`, `Money`, `Address`, `OrderID`

#### Aggregates and Aggregate Roots
- Aggregate root controls all access to internal entities
- Enforce consistency boundaries within a single transaction
- Keep aggregates small and focused
- Collect domain events internally; publish after persistence

#### Repositories
- One repository per aggregate root
- Abstract interface in domain layer; implementation in infrastructure
- Methods: `save`, `findByID`, domain-specific finders

#### Domain Services
- Stateless operations that don't naturally fit an entity or value object
- Coordinate between aggregates (e.g., `PricingService`, `TransferService`)

#### Domain Events
- Named in past tense: `OrderConfirmed`, `PaymentReceived`
- Carry aggregate ID and occurred-at timestamp
- Enable loose coupling between bounded contexts

## DDD Patterns and Best Practices

### Aggregate Design Rules
- Keep aggregates small and focused
- Ensure consistency boundaries are clear
- Use aggregate roots to control access
- Implement optimistic concurrency control

### Bounded Context Implementation
- Use separate modules/packages per bounded context
- Define clear interfaces between contexts
- Implement mapping/translation layers at boundaries
- Use domain events for loose coupling across contexts

### When to Use DDD
- Complex business domains with intricate rules
- Long-term projects requiring maintainability
- Teams collaborating with domain experts
- Systems requiring clear domain boundaries

### When Not to Use DDD
- Simple CRUD applications
- Short-lived prototypes
- Teams without domain expert access
- Performance-critical low-level systems

### Common Pitfalls
- **Anemic Domain Models**: Avoid entities with only data and no behavior
- **Over-engineering**: Start simple, add complexity as needed
- **Incorrect Boundaries**: Regularly review and adjust bounded contexts
- **Ignoring Ubiquitous Language**: Maintain consistency between code and business

## Complete Reference

For exhaustive patterns, examples, and advanced usage see:

**[`references/full-reference.md`](references/full-reference.md)**