Adopting Domain-Driven Design in your organization
@aleixyz
Thanks to DDD Barcelona to organize and marfeel for hosting this event :-)
2
DDD to Simplify,
Not to Complicate
3
When you try to explain DDD to your colleagues for first time
4
DDD is about
Discussion, listening, understanding, discovery, and business value, all in effort to centralize knowledge.
Two main things to have in mind always
5
From Strategic to Tactical patterns depending on your role
6
Strategic Patterns
7
Domain, Subdomain and Bounded Context
8
Image from Implementing Domain Driven Design - Vaughn Vernon
How you divide in subdomains should reflect your organization structure.
It helps you take better decisions; where to invest, what to outsource.
To apply it in your organization, you will need decision maker support or be a decision maker.
If you’re an Architect, it helps you to determine the amount and the size of the (micro)services.
Bounded contexts helps to organize in feature teams
9
Bounded contexts helps to organize in feature teams
10
Identify your domain expert
The domain expert can be:
Often is multiple people
11
Ubiquitous Language - Before DDD
12
Similar to an illustration of IDDD book
Ubiquitous Language - After DDD (with some luck)
13
Tools that help create a ubiquitous language
From Business side:
From Technical side:
14
Long run
“Quick win”
Tools that help create a ubiquitous language
In summary
Business People and Technical people have to talk often using the Business Language
and use that language in your code
Don’t be afraid to ask, we are here to learn about the domain
15
Situations that will/might be familiar
16
Reflection
Does the Business talk about nulls?
How are you modeling the absence of?
How would you model explicitly the absence of?
17
Book recommendations
18
Video recommendation
19
Readable Code - Laura Savino - DDD Europe 2018
Domain Language throughout Tests, combining DDD and BDD - Kenny Baas - DDD Europe 2018
Tactical Patterns
20
Do I need ...
in order to adopt Domain-Driven Design in my organization?
NO! You need to adapt the tools DDD brings to you in your organization context.
Don’t throw the towel just because (for example) Event Storming didn’t work.
21
My recommendation based on my experience
Focus on:
Easy to apply with most frameworks
Use only with proof that these are necessary/helpful:
22
Fast example
23
Identify anemic models
24
You might have Controller Architecture in your project (when CRUD has domain logic).
If your model has setters, it likely (it is…) to be an anemic model.
First step. Eradicate Setters
25
Be aware that you introduced technical debt, it’s OK as long as you are aware of it.
Next step. Identify Value Objects
❓❓❕❕
26
Value Objects add stability to your code base.
We choose to be coupled to the DB through those (evil?) annotations until we manage to decouple from DB instead to the UI.
Is User finished? Probably not. Value Objects are a good candidate to be an EntityId for example.
Next step: Application Service
Application Service
27
Their work is:
Helps re-usability
28
Example of entity using ubiquitous language.
Given a User,
When he/she wants to see a video in a public playlist,
Then he/she is allowed to
Given a User,
When he/she request permission to see a video in a private playlist,
And he/she isn’t in the member list
Then he/she the permission is rejected
Given a User,
When he/she request permission to see a video in a private playlist,
And he/she is in the member list
Then he/she the permission is granted
Recommendations
This needs to be iterative, choose a User Story and apply this steps. It will help you to know where to stop refactoring. Small steps.
29
Remember that
30
Summary
31
If I recommend you a book for your team it would be
32
https://www.manning.com/books/secure-by-design (just 375 pages…)
33
Fast introduction to DDD to your team mates
34
Q&A
Thank you for your time! :-)
35