Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 49 Publicité

Plus De Contenu Connexe

Plus par Guillaume Saint Etienne (15)

Plus récents (20)

Publicité

DDD FOR POs.pdf

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

×