discover DDD

1. DDD : des outils stratégiques pour le
Product Management
Découvrez le Domain Story Telling

2. Au départ...

3. (C) Scott Wlaschin - Domain Modeling Made Functional

4. Motivations
➢ “Ce qui part en production, c’est ce que les développeurs ont compris”
➢ le Métier est plus important que la technique (les utilisateurs n’achètent pas du code)
➢ le Métier est indépendant de la technique
➢ le Métier détermine ses propres invariants
➢ le Métier est difficile à appréhender
➢ “la Langue est la meilleure et la pire des choses” (Ésope, 6e siècle av. JC)
cf l’excellent exposé du regretté Alain Rey

5. Qui êtes vous?
Qui a vu un client?
Qui a parlé un à client?
Qui s’est mis à la place du client?
Qui a parlé un à développeur?
Qui a vu/lu du code?
Qui s’est mis avec le développeur pour coder ou se faire expliquer ?

6. Avez entendu parler de DéDéDé ?

7. DDD n’est pas
• Une méthode
• Un framework
• Une technique
• Un outil
7

8. ma vision du DDD
🧠 Une façon de penser
🚀 Un voyage
🔧 Empirique
🏗 En évolution perpétuelle
󰙍 Soumis à interprétation
👁 Compatible (très) avec l’Agilité
🧱 Compatible (très) avec XP / Craftsmanship
󰩃 La seule façon réaliste de réaliser un logiciel réussi

9. Meet DDD people

10. La proposition : “Tacler” la Complexité
3 niveaux
★ Exploratoire
★ Stratégique
★ Tactique

11. https://github.com/
ddd-crew/ddd-start
er-modelling-proce
ss

13. DDD key principles
• Domain Experts
○ They are the ones who carry the knowledge which defines the problem and what the output of the software should be in order
to be considered a complete solution, and they can define acceptance tests for this software
• Ubiquitous Language
○ When developing software it is important that the domain experts and the developers would create a language of expressions
and common phrases that define the system's model and interactions.
○ Bounded to context
• Bounded Contexts
○ Bounded contexts are, in their hearts, the application of the Separation of Concerns principle on the domain level.
○ Enforces the Model integrity
○ They are to be designed
○ In close relationship with the Ubiquitous Language -> Linguistic / semantic boundaries
○ Ownership boundaries, physical boundaries
13
DDD ce n’est pas (que) parler d'Agrégats, Entités, Value Objets, Repository (le mot savant pour BdD)
DDD c’est modéliser un domaine métier dans le langage de ses utilisateurs et experts (hus et coutumes)
Vaugh Vernon (et moi)

15. Figure 1. The Ubiquitous Language
should be the only language used to
express a model.
Everybody in the team should be able to
agree on every specific term without
ambiguities and no translation should be
needed
https://www.infoq.com/articles/ddd-contextmapping/

16. Au fait, c’est quoi un domaine métier ?
Ethymologie Wikipediesque:
Dérivé de l'ancien français « menestier » (ixe
siècle), «
mistier », puis « mestier » (xie
siècle), hérité du latin
populaire « misterium » et du latin classique «
ministerium ».
Signifie initialement le « besoin », puis le « service »
ou la « fonction »1.
C'est un doublet populaire de ministère (au service
de), issu du latin chrétien pour « service divin » Io Deo
menestier2.

17. Par où commencer ?

18. Qu’est ce qu’un
DOMAINE?
The domain is the set of concepts
that, through use-cases, allows
people in the enterprise to solve
problems.
Un domaine est un ensemble de fonctionnalités,
exprimées par des Use Cases/User Stories qui permet
à une entreprise de résoudre des problèmes de
manière soutenable et durable.

19. https://github.com/ddd-crew/ddd-starter-modelling-process

21. Tactique
Stratégique

22. Tactique
Stratégique

23. Tactical DDD in a Nutshell
• DDD is not a framework, but it does have a set of building blocks or concepts that you can incorporate into
your solution:
• The Ubiquitous language
• The Domain Model
○ Entities
○ Value objects
○ Aggregates and aggregate roots
• Domain services
• Application services
• Hexagonal Architecture ⏭ Functional Core + Imperative Shell
• Repository (stockage, entrepots, data science)
• CQRS (Command Query Responsibility Segregation)
• (+ Event Sourcing)
23

24. Stratégique Tactique

25. Palettes d’outils
• Impact Mapping
• Story Mapping
• The Business Model Canvas
• The Product Strategy Canvas
• Event Storming
• Event Modeling
• Domain Story Telling
• Wardley Maps
• Bounded Context Maps

26. Ubiquitous
Language Des outils pour l’appréhender:
● Atelier “Wording”
● User Journey
● Example Mapping
● Event Storming
● Event Modeling
● Domain Story Telling
plus formel
moins formel

27. Diviser pour mieux régner
Trouver les espaces du problème
Comprendre le(s) contexte(s)
Dessiner les contours, trouver les frontières (Boundaries, Bounded Contexts)
Etablir les relations entre les contextes

28. Quelques mots sur Event Storming
• Principe
• Pour qui?
• Quand ?
• Que peut-on en attendre?
https://kalele.io/why-eventstorming-pra

29. Quelques mots sur Event Modeling
• Principe
• Pour qui?
• Quand ?
• Que peut-on en attendre?
https://kalele.io/why-eventstorming-practitio
ners-should-try-domain-storytelling/

30. Domain Story Telling

31. Principes simples
• Un Board (en ligne ou sur posters)
• Des icônes
• Des flèches
• Des numéros
• Des mots
• (recommencer)

32. Une règle
Uniquement des actions
• Sujet
• Verbe
• Complément
Raconter une histoire par des scénarios simples

33. Le temps est votre ami
Numérotez les séquences des actions:
1 ⏭ 2 ⏭ 3 ...
“D’abord” ⏭ “ensuite” ⏭ “et puis” ⏭
“alors”

34. Une contrainte
Ne jamais établir d’actions parallèles
Pas de
• “et si”
• “en cas de”
• “ou”
SOLUTION => nouveau scénario pour nouvelle branche ou nouveau cas

35. Tips
➔ Pensez à la narration
➔ Que se passe-t-il ? et pourquoi ?
➔ Oubliez les données, pensez entités
➔ La narration, les actions, les conséquences
➔ Je vous ai parlé de la narration?

36. Hands on!
Voici l’espace du problème

37. Silence, on tourne!
https://actintheatre.com/fr/se-passe-t-tournage-de-cinema/
https://apprendre-le-cinema.fr/3-elements-reussir-tournage/

38. C’est parti pour le mariage

39. Soyez créatifs
Sortez vos plus beau dessins
• Facilitation Graphique
Sortez vos plus belles icônes
• Google icons
• Miro
• Klaxoon
• Excalidraw.com
○ Storytelling icons
○ Valentine's Day
○ Comms Platform Icons
○ Robots
○ Office Items
○ Awesome Icons #
○ Stick Figures

40. A vous de jouer...
https://openpracticelibrary.com/practice/domain-storytelling/

41. Et ensuite?
Les schémas alimentent la phase tactique.
Tout est là (ou presque):
• les bons noms
• les bonnes actions
• les bonnes conséquences
• les bonnes séquences (“et puis”)

42. Vers le tactique
Tout est là (ou presque):
● les bons noms
● les bonnes actions
● les bonnes conséquences
● les bonnes séquences
=> Domain Model
➔ Agrégats
➔ Entités
➔ Objets-Valeurs

43. Vers le tactique
Tout est là (ou presque):
● les bons noms
● les bonnes actions
● les bonnes conséquences
● les bonnes séquences
=> Domain Model
➔ Verbes

44. Vers le tactique
Tout est là (ou presque):
● les bons noms
● les bonnes actions
● les bonnes conséquences
● les bonnes séquences
=> Domain Model
➔ Invariants
➔ Règles Métier

45. Vers le tactique
Tout est là (ou presque):
● les bons noms
● les bonnes actions
● les bonnes conséquences
● les bonnes séquences
➔ Domain services
➔ Application services

47. Boucles
https://medium.com/@heidihelfand/the-dynamic-reteaming-ecocycle-3955fdf037e
Domaine Modèle
Equipe
D’après Nick Tune
inspire
transcrit
enrichit

48. Must see: DDD for Domain Experts & Product
Owners - Zsofia Herendi -
https://www.youtube.com/watch?v=2rgwit63XH4
https://drive.google.com/file/d/1cIMdatvI2o3OjGnqnjQX6p6VQWfQAL5Z/view

49. Merci