Domain Driven Design is not yet another methodology prescribing what to do when in the software development cycle. Domain Driven Design is a mindset, a philosophy on how to approach everything surrounding software development. Through Ubiquitous Language, the whole team (developers, engineers, clients and others) can collaborate in the same way. This language also determines how the software is built and is different from one bounded context to another. Therefore, Domain Driven Design facilitates verifying whether your team is building the right thing and speeds up the process of noticing mistakes. A positive side effect includes that great software will be produced.

1. What’s in it for you?
Closer collaboration
with the team
Avoid common
development problems
Pick investments
wisely
Ubiquitous language
We get better communication between the team and the
domain experts by using the same language. Take for example
the case of a restaurant using Deliveroo for deliveries.
Bounded context
CORE Concepts
We need a language we can speak that is understood by all
people involved. This language should be very precise, and this
language should be everywhere.
In Domain driven design we put a strict boundary around
the context. This boundary ensures meaning of concepts, as
long as you stay within its confines.
- Hard to grasp
- Confusion
Easier to understand -
Clear concept -
It’s a constant discovery process
to understand the problem that a
business wants solved in software.
We have to see that the business
wants to reach business goals.
Domain Driven Design assists in
realizing those goals by creating
applications which deliver true
business value.
the “Blue Book“
It all started with
DDD is a mindset,
not a methodology
— Anonymous coward
Domain Driven Design
Tackling Complexity in the Heart of Software