Definition: Software design approach that centers architecture around the business domain and its logic, using bounded contexts and ubiquitous language to manage complexity.
— Source: NERVICO, Product Development Consultancy
What is Domain-Driven Design
Domain-Driven Design (DDD) is a software design approach that centers architecture around the business domain and its logic. Proposed by Eric Evans in 2003, DDD provides conceptual tools such as bounded contexts, aggregates, and ubiquitous language for building systems that faithfully reflect the complexity of the business they serve.
How it works
DDD begins with close collaboration between developers and domain experts to establish a ubiquitous language: a shared vocabulary used in both conversations and code. The system is divided into bounded contexts, each with its own data model and business rules. Within each context, aggregates group related entities and ensure consistency. Domain events communicate what happens between contexts. Repositories abstract data access, and domain services encapsulate logic that does not belong to any specific entity.
Why it matters
In complex systems, the greatest challenge is not technology but understanding and correctly modeling the business. DDD ensures that code structure reflects business structure, making it easier for business rule changes to translate directly into predictable code changes. It also guides critical architectural decisions, such as where to split microservices or which teams should own each part of the system.
Practical example
A logistics company applies DDD to model its system. It identifies three bounded contexts: shipment management, billing, and fleet tracking. In the shipment context, “Package” is an aggregate with its own rules: maximum weight, allowed dimensions, destination restrictions. In billing, the same package is represented differently, with tax data and tariffs. Each context has its own model, and they communicate through domain events. When the shipment context emits “PackageDelivered,” the billing context automatically generates the final invoice.
Related terms
- Clean Architecture - Structural pattern that complements DDD by separating layers of responsibility
- Microservices - Architecture where DDD bounded contexts guide service boundaries
- CQRS - Pattern frequently applied within DDD contexts to optimize reads and writes
Last updated: February 2026