SlideShare une entreprise Scribd logo
1  sur  49
Télécharger pour lire hors ligne
DDD : des outils stratégiques pour le
Product Management
Découvrez le Domain Story Telling
Au départ...
(C) Scott Wlaschin - Domain Modeling Made Functional
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
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 ?
Avez entendu parler de DéDéDé ?
DDD n’est pas
• Une méthode
• Un framework
• Une technique
• Un outil
7
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
Meet DDD people
La proposition : “Tacler” la Complexité
3 niveaux
★ Exploratoire
★ Stratégique
★ Tactique
https://github.com/
ddd-crew/ddd-start
er-modelling-proce
ss
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)
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/
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.
Par où commencer ?
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.
https://github.com/ddd-crew/ddd-starter-modelling-process
Tactique
Stratégique
Tactique
Stratégique
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
Stratégique Tactique
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
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
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
Quelques mots sur Event Storming
• Principe
• Pour qui?
• Quand ?
• Que peut-on en attendre?
https://kalele.io/why-eventstorming-pra
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/
Domain Story Telling
Principes simples
• Un Board (en ligne ou sur posters)
• Des icônes
• Des flèches
• Des numéros
• Des mots
• (recommencer)
Une règle
Uniquement des actions
• Sujet
• Verbe
• Complément
Raconter une histoire par des scénarios simples
Le temps est votre ami
Numérotez les séquences des actions:
1 ⏭ 2 ⏭ 3 ...
“D’abord” ⏭ “ensuite” ⏭ “et puis” ⏭
“alors”
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
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?
Hands on!
Voici l’espace du problème
Silence, on tourne!
https://actintheatre.com/fr/se-passe-t-tournage-de-cinema/
https://apprendre-le-cinema.fr/3-elements-reussir-tournage/
C’est parti pour le mariage
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
A vous de jouer...
https://openpracticelibrary.com/practice/domain-storytelling/
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”)
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
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
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
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
Boucles
https://medium.com/@heidihelfand/the-dynamic-reteaming-ecocycle-3955fdf037e
Domaine Modèle
Equipe
D’après Nick Tune
inspire
transcrit
enrichit
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
Merci

Contenu connexe

Similaire à DDD FOR POs.pdf

introduction à la gestion de projet
introduction à la gestion de projetintroduction à la gestion de projet
introduction à la gestion de projet
laureno
 
Ged Open Source - Documation 2010
Ged Open Source - Documation 2010Ged Open Source - Documation 2010
Ged Open Source - Documation 2010
Thomas Choppy
 

Similaire à DDD FOR POs.pdf (20)

Domain Driven Design - Agile France 2010
Domain Driven Design - Agile France 2010Domain Driven Design - Agile France 2010
Domain Driven Design - Agile France 2010
 
introduction à la gestion de projet
introduction à la gestion de projetintroduction à la gestion de projet
introduction à la gestion de projet
 
Projet+com02.ppt
Projet+com02.pptProjet+com02.ppt
Projet+com02.ppt
 
Pourquoi devenir développeur - by Joane SETANGNI
Pourquoi devenir développeur - by Joane SETANGNIPourquoi devenir développeur - by Joane SETANGNI
Pourquoi devenir développeur - by Joane SETANGNI
 
DDD session BrownBagLunch (FR)
DDD session BrownBagLunch (FR)DDD session BrownBagLunch (FR)
DDD session BrownBagLunch (FR)
 
Ged Open Source - Documation 2010
Ged Open Source - Documation 2010Ged Open Source - Documation 2010
Ged Open Source - Documation 2010
 
Le rôle de l’architecte Agile - Mathieu Boisvert
Le rôle de l’architecte Agile - Mathieu BoisvertLe rôle de l’architecte Agile - Mathieu Boisvert
Le rôle de l’architecte Agile - Mathieu Boisvert
 
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
 
C'est une bonne situation ça, Staff Engineer ? 😉 (@DevoxxFR 2024)
C'est une bonne situation ça, Staff Engineer ? 😉 (@DevoxxFR 2024)C'est une bonne situation ça, Staff Engineer ? 😉 (@DevoxxFR 2024)
C'est une bonne situation ça, Staff Engineer ? 😉 (@DevoxxFR 2024)
 
Des conférences à voir et à revoir
Des conférences à voir et à revoirDes conférences à voir et à revoir
Des conférences à voir et à revoir
 
Mockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice Duteil
 
Une transformation tout (ou presque) sauf digitale
Une transformation tout (ou presque) sauf digitaleUne transformation tout (ou presque) sauf digitale
Une transformation tout (ou presque) sauf digitale
 
Des jeux et des devops
Des jeux et des devopsDes jeux et des devops
Des jeux et des devops
 
L’ergonomie et l’expérience utilisateur en contexte agile (Agile UX Masterclass)
L’ergonomie et l’expérience utilisateur en contexte agile (Agile UX Masterclass)L’ergonomie et l’expérience utilisateur en contexte agile (Agile UX Masterclass)
L’ergonomie et l’expérience utilisateur en contexte agile (Agile UX Masterclass)
 
Catopsys - Une startup agile et lean
Catopsys - Une startup agile et lean Catopsys - Une startup agile et lean
Catopsys - Une startup agile et lean
 
Optimiser l'expérience utilisateur de l'Open Source
Optimiser l'expérience utilisateur de l'Open SourceOptimiser l'expérience utilisateur de l'Open Source
Optimiser l'expérience utilisateur de l'Open Source
 
10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx
 
Le gameday...un concept devopsludique
Le gameday...un concept devopsludiqueLe gameday...un concept devopsludique
Le gameday...un concept devopsludique
 
Agile Tour Toulouse jl-letouzey
Agile Tour Toulouse jl-letouzeyAgile Tour Toulouse jl-letouzey
Agile Tour Toulouse jl-letouzey
 
(Re) Cadrage en équipe agile (Intégrer Scrum et Design Thinking : REX)
(Re) Cadrage en équipe agile (Intégrer Scrum et Design Thinking : REX)(Re) Cadrage en équipe agile (Intégrer Scrum et Design Thinking : REX)
(Re) Cadrage en équipe agile (Intégrer Scrum et Design Thinking : REX)
 

Plus de Guillaume Saint Etienne

Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
Guillaume Saint Etienne
 
Electronic Music and Software Craftsmanship: analogue patterns.
Electronic Music and Software Craftsmanship: analogue patterns.Electronic Music and Software Craftsmanship: analogue patterns.
Electronic Music and Software Craftsmanship: analogue patterns.
Guillaume Saint Etienne
 

Plus de Guillaume Saint Etienne (20)

Ecologie du Logiciel (Craft Luxembourg 2022).pdf
Ecologie du Logiciel (Craft Luxembourg 2022).pdfEcologie du Logiciel (Craft Luxembourg 2022).pdf
Ecologie du Logiciel (Craft Luxembourg 2022).pdf
 
musique electronique au cinéma.pptx
musique electronique au cinéma.pptxmusique electronique au cinéma.pptx
musique electronique au cinéma.pptx
 
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
 
des algoritmes et des hommes (ethique et code).pdf
des algoritmes et des hommes (ethique et code).pdfdes algoritmes et des hommes (ethique et code).pdf
des algoritmes et des hommes (ethique et code).pdf
 
La crise Agile chez les Developpeurs (AGrenoble2019) (1).pdf
La crise Agile chez les Developpeurs (AGrenoble2019) (1).pdfLa crise Agile chez les Developpeurs (AGrenoble2019) (1).pdf
La crise Agile chez les Developpeurs (AGrenoble2019) (1).pdf
 
How we can BUILD.pdf
How we can BUILD.pdfHow we can BUILD.pdf
How we can BUILD.pdf
 
des mutants dans le code.pdf
des mutants dans le code.pdfdes mutants dans le code.pdf
des mutants dans le code.pdf
 
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
 
Il n’y a pas de bons développeurs.pptx
Il n’y a pas de bons développeurs.pptxIl n’y a pas de bons développeurs.pptx
Il n’y a pas de bons développeurs.pptx
 
Living Documentation (TDD, BDD).pptx
Living Documentation (TDD, BDD).pptxLiving Documentation (TDD, BDD).pptx
Living Documentation (TDD, BDD).pptx
 
Agile pour l'echafaud ATT2020.pptx
Agile pour l'echafaud ATT2020.pptxAgile pour l'echafaud ATT2020.pptx
Agile pour l'echafaud ATT2020.pptx
 
Vendredi Tech_ la programmation fonctionnelle.pptx
Vendredi Tech_ la programmation fonctionnelle.pptxVendredi Tech_ la programmation fonctionnelle.pptx
Vendredi Tech_ la programmation fonctionnelle.pptx
 
Feedback on DDD Europe - short -event storming.pptx
Feedback on DDD Europe - short -event storming.pptxFeedback on DDD Europe - short -event storming.pptx
Feedback on DDD Europe - short -event storming.pptx
 
Crise agile chez les développeurs (frug agile 2020)
Crise agile chez les développeurs (frug agile 2020)Crise agile chez les développeurs (frug agile 2020)
Crise agile chez les développeurs (frug agile 2020)
 
My feedback on ddd europe
My feedback on ddd europeMy feedback on ddd europe
My feedback on ddd europe
 
Electronic Music and Software Craftsmanship: analogue patterns.
Electronic Music and Software Craftsmanship: analogue patterns.Electronic Music and Software Craftsmanship: analogue patterns.
Electronic Music and Software Craftsmanship: analogue patterns.
 
Tdd vs SQL
Tdd vs SQLTdd vs SQL
Tdd vs SQL
 
Clean architectures
Clean architecturesClean architectures
Clean architectures
 
Services & Contrats Agiles
Services & Contrats AgilesServices & Contrats Agiles
Services & Contrats Agiles
 
AGILE TOUR 2009: agilité et services
AGILE TOUR 2009:   agilité et servicesAGILE TOUR 2009:   agilité et services
AGILE TOUR 2009: agilité et services
 

DDD FOR POs.pdf

  • 1. DDD : des outils stratégiques pour le Product Management Découvrez le Domain Story Telling
  • 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
  • 10. La proposition : “Tacler” la Complexité 3 niveaux ★ Exploratoire ★ Stratégique ★ Tactique
  • 12.
  • 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)
  • 14.
  • 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.
  • 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.
  • 20.
  • 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
  • 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/
  • 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?
  • 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
  • 46.
  • 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