Domain-Driven Design (DDD)
Domain-Driven Design (DDD) is a software design approach, introduced by Eric Evans, that structures complex software around a deep model of the business domain it serves, using a shared "ubiquitous language" between developers and domain…
Definition
Domain-Driven Design (DDD) is a software design approach, introduced by Eric Evans, that structures complex software around a deep model of the business domain it serves, using a shared "ubiquitous language" between developers and domain experts.
Overview
DDD's central premise is that the hardest part of building complex software isn't technical implementation but correctly capturing the business domain's rules, terminology, and boundaries — so DDD pushes teams to collaborate closely with domain experts and encode that shared understanding directly into the code's structure and naming, an idea Evans called the "ubiquitous language." Rather than one monolithic model covering an entire business, DDD introduces "bounded contexts" — explicit boundaries within which a particular model and vocabulary are consistent, acknowledging that terms like "customer" may legitimately mean different things in billing versus support contexts. DDD also introduces tactical patterns for structuring code within a bounded context: entities (objects with persistent identity), value objects (defined purely by their attributes), aggregates (clusters of objects treated as a consistency boundary), and repositories (abstractions for retrieving and persisting aggregates). These tactical patterns are often implemented using object-oriented programming (OOP) and frequently draw on classic design patterns, but DDD's real emphasis is strategic — getting the domain boundaries and shared language right before worrying about implementation details. DDD is best suited to genuinely complex business domains with intricate rules, where the cost of modeling mismatches is high; for simple CRUD applications, its overhead (bounded contexts, ubiquitous language workshops, aggregate design) is often unnecessary. It has become closely associated with microservices architecture, since bounded contexts map naturally onto independently deployable services with clear ownership boundaries. It is often mentioned alongside SOLID Principles in this space.
Key Concepts
- Ubiquitous language shared between developers and domain experts
- Bounded contexts define explicit model and vocabulary boundaries
- Tactical patterns: entities, value objects, aggregates, repositories
- Strategic focus on correctly modeling business complexity
- Introduced by Eric Evans in his 2003 book of the same name
- Closely associated with microservices architecture design
Use Cases
Frequently Asked Questions
From the Blog
What Is Test-Driven Development (TDD)?
Test-driven development is writing a failing test before the code that makes it pass. Learn the red-green-refactor cycle, its benefits, and how to start.
Read More Data ScienceWhat Is A/B Testing? A Data-Driven Guide
A/B testing compares two versions of something to see which performs better using real data. Learn how to design, run, and interpret experiments correctly.
Read More AI & TechnologyWhat Is DNS? How the Domain Name System Works
DNS, the Domain Name System, translates human-readable website names into the numeric IP addresses computers use to find each other. This guide explains how DNS lookups work step by step and why they matter.
Read More AI & TechnologyContinued Pretraining vs Fine-Tuning for Domain Language
Continued pretraining teaches a model a domain's vocabulary and conventions from raw text; fine-tuning teaches it how to behave on a task from input-output pairs. This explains which problem each solves, how to tell them apart from your symptoms, and how to sequence them when you need both.
Read More