Domain-Driven Design definition
In Domain-Driven Design, software concepts follow the language of domain experts. Teams make boundaries explicit, protect business invariants, and connect strategic decisions to tactical implementation.
People searching for “DDD” or “Domain-Driven Design” usually want a clear definition, the difference between strategic and tactical design, and how DDD relates to Bounded Contexts, Aggregates, Event Storming, and CQRS.
- Ubiquitous language shared by experts and developers
- Bounded Contexts as consistency boundaries for meaning
- Aggregates that protect business invariants
- Explicit relationships between models and processes
What problem does Domain-Driven Design solve?
As systems grow, the same words acquire different meanings, rules become scattered across services, and architectural decisions disappear into code. DDD makes those differences visible and gives teams a way to decide where a model is consistent and where translation is required.
- Align software concepts with the language of domain experts
- Separate models that have different meanings or rates of change
- Protect business invariants inside explicit consistency boundaries
- Connect strategic decisions to tactical implementation
Strategic and tactical design
Strategic design divides the problem into Bounded Contexts and describes how they collaborate. Tactical design models behavior inside a context with Aggregates, Commands, Domain Events, Policies, Value Objects, and Repositories. One without the other is incomplete: boundaries without behavior are boxes, while tactical patterns without boundaries become a shared model that grows without control.
DDD in an AI-assisted workflow
AI can produce implementation quickly, but it still needs a precise account of terminology, boundaries, invariants, processes, and expected outcomes. A connected domain model gives humans a place to make those decisions and gives AI better context for implementation.
Domain-Driven Design FAQ
What is Domain-Driven Design (DDD)?
Domain-Driven Design is an approach to software design that puts domain knowledge, explicit boundaries, and a shared ubiquitous language at the center of architecture. It helps teams model business rules clearly before implementation, especially in complex systems.
When should you use DDD?
Use DDD when business complexity is high: terms have multiple meanings, rules change often, or several teams own different parts of the domain. For simple CRUD systems with stable language, lighter modeling is usually enough.
What is the difference between strategic and tactical DDD?
Strategic DDD divides the problem into Bounded Contexts and describes how they collaborate on a Context Map. Tactical DDD models behavior inside a context with Aggregates, Commands, Domain Events, Policies, Value Objects, and Repositories.
How does DDD relate to CQRS and Event Storming?
Event Storming discovers domain behavior and candidate boundaries. Bounded Contexts and Aggregates organize meaning and invariants. CQRS separates write decisions from read models when queries need different shapes from the write side.
Does DDD require microservices?
No. DDD is about models and boundaries, not deployment topology. A Bounded Context can live in a modular monolith or in microservices. Start from language and responsibility, then choose deployment.
DDDesigner
Example: placing an order
A PlaceOrder Business Action starts with a customer intention. Event Storming reveals OrderPlaced, payment, inventory, and shipping facts. Context Mapping separates Ordering, Payments, Inventory, and Shipping. The Order Aggregate protects its invariants; a Saga coordinates the long-running flow; a CQRS projection serves the order-status screen.
Start free