SHORT ANSWER
Domain-driven design (DDD) is a way of building software that mirrors how the business works. Developers and domain experts agree on one shared vocabulary, split a large system into bounded contexts with clear edges and write that model straight into the code. Eric Evans introduced it in his 2003 book. Teams use it to find service boundaries and to break up complex legacy systems without cutting in the wrong places.
Domain-driven design (DDD) is a way of designing software around the business it serves. Developers and domain experts build a shared model of how the business works, name things the same way and write that model directly into the code. Eric Evans introduced the approach in his 2003 book. It pays off in systems where business rules, not technology, are the hard part.
How does domain-driven design work?
Ubiquitous language: the team agrees on precise business terms and uses them in meetings, documents and code.
Subdomains: you split the business into core, supporting and generic areas and spend most of your effort on the core.
Bounded contexts: each part of the system has its own model and clear edges, usually owned by one team.
Context mapping: you make the relationships between contexts explicit, including the data and events they exchange.
Tactical patterns: inside a context, entities, value objects, aggregates and domain events give the code its structure.
Most teams find their domains and boundaries in a workshop. Our Event Storming guide shows how that works in practice.
Why does DDD matter for enterprises?
Large systems often go wrong because two departments use the same word for different things, and the code mixes both meanings into one tangled model. DDD draws boundaries that match how the organisation works, so a team can change its part without breaking someone else’s. That makes it a solid base for legacy application modernisation, microservices and data mesh, which applies domain ownership to analytical data.
In our workshops, the most useful moment is often when two teams realise they mean different things by “order” or “customer”. Sorting that out on a wall of sticky notes takes an afternoon. Sorting it out after both meanings are in production code takes much longer.
Example: one term, two bounded contexts
| Sales context | Warehouse context |
|---|---|---|
What “order” means | A customer’s commitment to buy | A set of items to pick and ship |
Key attributes | Price, discount, customer | Location, weight, carrier |
Owned by | Sales systems team | Logistics systems team |
How they connect | Publishes OrderPlaced event | Consumes OrderPlaced event |
Use DDD where it earns its keep. The core domain, where rules are complex and set you apart (pricing, underwriting, production planning), deserves the full treatment. Generic areas like authentication or invoicing are usually better served by standard products. Applying every tactical pattern everywhere adds complexity for no gain, so experienced teams use DDD selectively and put their energy into getting the boundaries right.
How RUBICON helps with domain-driven design
We run Event Storming, Lean Inception and Design Sprint workshops, then use the domain model from those sessions to design and modernise enterprise software. If you’re planning a new platform or splitting a monolith, our architects can map your domains with you.
Related terms
Frequently asked questions
What is a bounded context in DDD?
A bounded context is a part of a system where one model and its terms have a single, precise meaning. A customer in the billing context has payment details. A customer in the support context has tickets. One team usually owns each bounded context, and it often becomes one service or module. Clear contexts stop one meaning from leaking into code that expects another.
What is the difference between strategic and tactical DDD?
Strategic DDD covers the big picture: finding subdomains, drawing bounded contexts and deciding how they connect. Tactical DDD gives you building blocks for the code inside one context, such as entities, value objects, aggregates, domain events and repositories. Most teams get the biggest return from strategic DDD and use tactical patterns only where the business rules are complex enough to need them.
Is domain-driven design only for microservices?
No. DDD predates microservices and works just as well for a well-structured modular monolith. Microservices benefit from it because bounded contexts give natural service boundaries, so you avoid splitting the system in the wrong places. Many teams start with a modular monolith organised by bounded contexts and pull out separate services later, only where scaling or team ownership calls for it.
How does Event Storming relate to DDD?
Event Storming is a workshop technique created by Alberto Brandolini. The group maps a business process as a timeline of domain events on sticky notes. It's one of the fastest ways to find the shared language, subdomains and bounded contexts that DDD depends on, because developers and domain experts work on the same wall at the same time instead of trading documents.
More resources
