Although it is close to celebrating its 20th birthday, and despite many popularization attempts, Domain-Driven Design (DDD) remains a subject on which it is difficult to feel comfortable as a developer, and that seems too often reserved for an elite of architects inside the circles of power of an IT department. However, it is in the direct relationship to the code that DDD takes on its full meaning!
In this workshop, we offer some specific code practices to help you express more business flavor in your code. Step by step, starting from an existing and concrete code base, you will discover how a series of simple refactorings can bring out the business reasoning at the heart of DDD, and you will be surprised to say that you have finally really understood and practiced DDD!
2. WHY SHOULD WE LEARN DDD?
It’s so stylish! I want to do like
those who talk
about it.
For an awesome
resume!
It might be useful at
the end!
@ArnaudThiefaine @DorraBartaguiz
8. WHAT WE REPROACH THE DDD?
I am not an architect,
so I did not have the
opportunity to dig
I do not have access
to the organization's
strategic discussions
The organization
and the teams are
too hermetic to
make it
It is mainly used to
make bullshit
diagrams
It does not go back
to the code
@ArnaudThiefaine @DorraBartaguiz
9. SUMMARY
• Modelling Kata (Theater Kata)
• Value Object to rescue primitive-obsessions
• Business and technic separation
• Sandwich pattern
• Hexagonal architecture
• Bounded Contexts identification
• Protect invariants
• Aggregate
• Entity
• Value Object
• Service & repository
• Separate Bounded Contexts
@ArnaudThiefaine @DorraBartaguiz
10. 50% VIP
35€ standard category
+50% for premium
THEATER KATA
Beatriz « The CICD »
@ArnaudThiefaine @DorraBartaguiz
31. REPOSITORY
• Collection-oriented
• Manage transaction
• in repo not the service
• Side Effect
• Injectable
• Ubiquitous language
• For naming
Domain
Repository
@ArnaudThiefaine @DorraBartaguiz
32. AGGREGATE
• Unique identity for the grape
• Aggregate Root
• Invariant to protect
• Consistence
• validity
• transactional (save/load)
Domain
Aggregate
@ArnaudThiefaine @DorraBartaguiz
36. Value object
No identity
Value equality
Immutable
Parametrized Constructor
Factory method
Side-effect-free
Entity
Unique identity
Evolves over time
Domain
Entity
ValueObject
@ArnaudThiefaine @DorraBartaguiz
44. SERVICE
• Stateless
• Injectable
• Business logic
• Neither in Value Object
• Nor in Entity
• Ubiquitous language
• For naming
Domain
Service
Service
@ArnaudThiefaine @DorraBartaguiz
45. Make sure you need a service. […]
Using Services overzealously will
usually result in the negative
consequences of creating an
Anemic Domain Model.
- Vaughn Vernon
Implementing Domain-Driven Design
@ArnaudThiefaine @DorraBartaguiz
