code & cannoli - domain driven design
TRANSCRIPT
Introduction to Domain Driven Design
Frank Levering• PHP Developer • DevMob
Quality software• Writing tests • Using design patterns • Manual testing • SOLID
Quality software doesn’t give an insurance for a quality
software model
Code example
Date - Name
It saves a customer no matter what, awesome right?
This model is suffering from Anemia
We have no idea under what business situations this
method is used
And it even gets worse
Code example
Date - Name
Can we really test this?
DDD helps you creating a more high-quality software
model
It helps you create software that makes sense to the
business
You would be making software that is as close as possible to what the
business leaders and experts would create if they were the developers
Disclaimer• A domain is not DNS or
anything internet related • Domain is the area your
business relies
So how does DDD work?• Strategic design • Tactical design
We will mostly be talking about strategic design today
Key concepts of strategic design• Domain experts • Ubiquitous language • Core Domains, Subdomains
and Domain Models • Bounded Contexts
Not doing any strategic design results in doing DDD-
Lite
Domain experts
Bringing domain experts and developers to the same playing field which produces software
that makes sense to the business
Introducing Ubiquitous language
It’s not the language of the business
It must not adopt industry standard terminology
It’s also not the language used by domain experts
It’s a shared language developed by a team, a team composed of both domain
experts and developers
Ubiquitous language develops on the way
No translations between the domain experts, software
developers and the software
Date - Name
Ubiquitous language is important when designing the behaviour of objects
Code example
Date - Name
Code example
Date - Name
This was kind of an extreme example
Code example
Date - Name
Code example
Date - Name
Domains
A domain, in the broad sense, is what an organisation does
But the term domain is a bit overloaded
So let’s use Core Domain and Subdomains
The whole Domain of the organisation is composed of
Subdomains
Retailer example
Date - Name
But what is the Core Domain?
Generic vs Supporting Subdomains
Why is this so important?
Developers like to focus on the technical part of a
product
We focus on Entities, Value Objects, Services,
Aggregates
By doing that, we blend core concepts with generic ones
Causing the creation of two models into one
Date - Name
Agile PM tool example
Date - Name
Focus on Core Domain
The Domain is your problem space
Domain Model
What is the Domain Model?
The Domain Model is your organisedand structured knowledge of the problem.• It should represent the
vocabulary and key concepts of the problem domain • It should identify the
relationships among all of the entities
It could be a diagram
Or written documentation
But in our case..
It’s a software model of the very specific domain you are working in
It should be accessible and understandable by everyone
involved in the project
Bounded Contexts
Bounded Context is an explicit boundary in which a
domain model exists
The boundary is created because each of the model’s concepts inside, with its properties and
operations, has a special meaning
Example with Bounded Contexts
Date - Name
Inside a Subdomain, you can have multiple Bounded
Contexts
A Bounded Context should be as big as it needs to be in order
to fully express its complete Ubiquitous Language
Concepts that are not truly part of the domain should be
factored out
Naming a Bounded Context
So why should you do DDD?
Bringing domain experts and developers to the same playing field which produces software
that makes sense to the business
You would be making software that is as close as possible to what the
business leaders and experts would create if they were the developers
Learning more about the business, both domain experts and developers
No translations between the domain experts, software
developers and the software
Centralizing knowledge is key
Thank you