---
title: Domain-Driven Design (DDD)
description: Principles and patterns of Domain-Driven Design
type: agent/instruction
tags: [architecture, design, methodology, modeling]
---

{{h1}}Domain-Driven Design (DDD)

{{h2}}Core Concepts

- {{b}}Ubiquitous Language{{b}}: Shared vocabulary between developers and domain experts, used in code and conversation
- {{b}}Bounded Context{{b}}: Explicit boundary where a model applies with its own ubiquitous language
- {{b}}Context Mapping{{b}}: Document relationships and integration patterns between bounded contexts

{{h2}}Strategic Patterns

{{h3}}Bounded Context Relationships
- {{b}}Partnership{{b}}: Close collaboration between contexts
- {{b}}Shared Kernel{{b}}: Small shared model
- {{b}}Customer-Supplier{{b}}: Downstream depends on upstream
- {{b}}Anticorruption Layer{{b}}: Translate between contexts
- {{b}}Conformist{{b}}: Downstream conforms to upstream

{{h2}}Tactical Patterns

{{h3}}Building Blocks

- {{b}}Entity{{b}}: Object with unique identity that persists through lifecycle
- {{b}}Value Object{{b}}: Immutable object defined by attributes, no unique identity
- {{b}}Aggregate{{b}}: Cluster with single root entity, consistency boundary, external references only to root
- {{b}}Repository{{b}}: Collection-like interface for accessing aggregates, one per aggregate root
- {{b}}Domain Service{{b}}: Stateless operations that don't belong to entities/value objects
- {{b}}Domain Event{{b}}: Immutable fact about past occurrence, enables loose coupling
- {{b}}Factory{{b}}: Encapsulates complex object creation

{{h3}}Aggregate Design Rules
1. Protect business invariants within boundaries
2. Design small aggregates
3. Reference other aggregates by identity only
4. Update one aggregate per transaction

{{h2}}Layered Architecture

```
User Interface    → Presentation
Application       → Use cases, orchestration (no business logic)
Domain            → Business rules, state, behaviour
Infrastructure    → Persistence, messaging, external services
```

{{h2}}Key Principles

- Code reflects the domain model
- Developers participate in modeling with domain experts
- Domain understanding evolves, refactor as knowledge grows
- Focus investment on core domain
- Keep aggregates small and focused

{{h2}}When to Use DDD

{{b}}Good Fit{{b}}: Complex business logic, domain experts available, long-lived systems, core competitive advantage

{{b}}Poor Fit{{b}}: Simple CRUD, data-centric systems, no domain complexity, short-term projects
