---
title: "DDD (Domain-Driven Design)"
description: "DDD (Domain-Driven Design) aligns code with the business domain via ubiquitous language, bounded contexts and aggregates. See when it pays off."
url: "https://nodea.io/en/glossary/domain-driven-design"
lang: "en"
updated: "2026-07-13"
---

# DDD (Domain-Driven Design)

> DDD (Domain-Driven Design) is a software design approach in which the code model mirrors the business domain, built on a shared language between developers and domain experts.

**DDD** (*Domain-Driven Design*) is an approach to building software in which the structure, vocabulary, and logic of the code mirror the business domain — the real-world problem space the system serves. Introduced by Eric Evans in his 2003 book, it rests on close collaboration between developers and domain experts and on a model that both groups understand identically.

## How Domain-Driven Design works

DDD operates on two levels. **Strategic design** organizes the big picture: the *ubiquitous language* enforces the same terms in conversations, documentation, and code; a *bounded context* defines the boundary within which a given model is valid (a “customer” means something different to sales than to collections); and *context maps* describe how those boundaries relate and integrate. **Tactical design** supplies the building blocks inside a context: entities (objects with identity), value objects (immutable, compared by attributes), aggregates (consistency boundaries with a single root enforcing invariants), repositories, domain services, and domain events that record business facts. Crucially, business logic lives in the domain model — not in controllers or the persistence layer — so the [framework](https://nodea.io/en/glossary/framework) and database remain replaceable infrastructure details.

## Practical applications

DDD shines in systems with rich, changing rules: payments, insurance, freight, billing, and large e-commerce platforms. Teams adopt it because:

- bounded contexts translate naturally into module or microservice boundaries and team ownership — DDD is the most common blueprint for slicing a monolith;
- the ubiquitous language collapses the gap between requirements and code, reducing translation errors;
- aggregates and domain events make data consistency and audit trails explicit;
- a pure domain model is easy to unit test, pairing well with [TDD](https://nodea.io/en/glossary/tdd) since business rules run without infrastructure.

The main pitfall is cargo-cult adoption: sprinkling repositories and value objects over a CRUD app adds ceremony without insight. Practitioners recommend starting with strategic design — talk to domain experts, name the contexts, agree on the language — and reaching for the tactical patterns only where the complexity genuinely lives.

### When is Domain-Driven Design worth using?

DDD pays off when the business logic is complex, evolving, and central to the product's value — banking, logistics, insurance, large marketplaces. For simple CRUD applications the modeling overhead outweighs the benefits; there, the strategic ideas alone — shared language and explicit context boundaries — are usually enough.

## Related

- [Framework](https://nodea.io/en/glossary/framework)
- [TDD](https://nodea.io/en/glossary/tdd)
- [Refactoring](https://nodea.io/en/glossary/refactoring)
- [API](https://nodea.io/en/glossary/api)
- [Agile](https://nodea.io/en/glossary/agile)

---

Languages: [pl](https://nodea.pl/pl/slownik-pojec/ddd.md)  
Site index: [llms.txt](https://nodea.io/en/llms.txt)