DDD Introduction
- 1. DOMAIN DRIVEN DESIGN ON Y VA EN 2019 !! Grégory BOISSINOT Passionate DDD Practitioner
- 2. DDD D D D
- 3. DOMAIN DRIVEN DESIGNApproche de conception logicielle pour créer des applications répondant mieux aux besoins des utilisateurs Focus sur les besoins du métier
- 4. DDD DOMAIN (LA RÉALITÉ) ▸ Une sphère de connaissances et d’activités propres à un métier ▸ Composée d’un vocabulaire spécialisé, d’un ensemble de règles, d’hypothèses, de concepts issus du monde réel ▸ Contient l’ensemble des cas d’usage à résoudre ▸ En interaction avec des experts métiers et des sphères d’influence
- 5. DDD LA GENÈSE (POUR NOUS TOUS) ▸ Être curieux sur le domaine ▸ Parler le langage métier ▸ Se focaliser sur les parties les plus importantes du logiciel ▸ Modeling <==> Code Premier livre académique
- 6. DDD UN CONTENU RICHE Des patterns, des principes et des pratiques pour faciliter la création d’applications de logique métier complexe
- 7. DDD L’ABOUTISSEMENT D’UNE MATURITÉ DE PRATIQUES
- 8. DDD UN ACCÉLÉRATEUR POUR LES ÉQUIPES PROJETS
- 9. DDD UNE BASE DE CODE SOURCE MAÎTRISÉE Sans le DDD Avec le DDD
- 10. NOTRE MÉTIER
- 11. DDD ON CHERCHE D’ABORD À RÉSOUDRE DES PROBLÈMES MÉTIER
- 12. DDD LE CONTEXTE EST ROI ! ▸ Concevoir, c’est prendre en compte le contexte ▸ Qui ? Quoi ? Comment ? Où ? ▸ En adéquation avec des contraintes ▸ Organisationnelles ▸ Techniques ▸ Humaines
- 13. DDD ET POURTANT !! DES CRISES À RÉSOUDRE PRESSION SUR LA DATE UN SYSTÈME PARFOIS DIFFICILE À MAINTENIR
- 14. DDD LA MÉCANIQUE “LÉGO-BRIQUE” DU DDD VA NOUS AIDER
- 17. DDD L’EXTRACTION DE L’ESSENCE MÉTIER - LE PRINCIPE KUVINGS
- 18. DDD L’EXISTANT “ Ce qu’on sait “ “ Ce qu’on a besoin d’apprendre “
- 19. DDD L’ART DE LA CONNAISSANCE La connaissance est un prérequis
- 20. DDD LES OBJECTIFS : IDENTIFIER, DÉCOMPOSER, CLASSIFIER Nous cherchons à identifier les parties les plus importantes
- 21. DDD COMPRÉHENSION DU DOMAINE - ANALYSIS PATTERNS
- 22. DDD COMPRÉHENSION DU DOMAINE - BIAN - MODÈLE STANDARD Banking Industry Architecture Network (BIAN)
- 23. DDD COMPRÉHENSION - ATELIERS DE COMMUNICATION & PARTAGE Des échanges autour d’un même domaine métier
- 24. DDD EVENT STORMING Tout est à propos de conversations autour d’un même langage sans ambiguïté
- 25. DDD EVENT STORMING - CRÉATION D’UN MODÈLE
- 26. DDD EVENT STORMING - EVENT & COMMAND On exprime les Event & Command explicitement
- 27. DDD EVENT STORMING - À LA FIN Des contextes explicites
- 28. DDD EVENT STORMING EN PRATIQUE ▸ Commencer par des sessions interactives de 2h ▸ Inviter les bonnes personnes ▸ Capitaliser immédiatement dans un outil collaboratif
- 29. DDD DOMAIN STORY TELLING & USER STORY MAPPING ▸ Souvent utilisé comme point d’entrée de l’atelier de l’Event Storming ▸ Permet d’obtenir des scénarios concrets ▸ Centré sur les cas d’utilisation les plus importants
- 31. DDD DOMAINE BANCAIRE - EXEMPLE DE DÉCOMPOSITION
- 32. DDD DOMAINE BANCAIRE - EXEMPLE DE DÉCOMPOSITION
- 33. DDD TECHNIQUES COMPLÉMENTAIRES - L’USAGE D’HEURISTIQUES ▸ Frontières naturelles ▸ Frontières linguistiques ▸ Equipes autonomes ▸ Autonomie des données ▸ etc
- 34. DDD SAVOIR ÉCRIRE LES SPÉCIFICATIONS
- 35. MODEL-DRIVEN
- 36. DDD UN MODÈLE : UNE ABSTRACTION DE LA RÉALITÉ PILOTÉ PAR UN CAS D’USAGE On souhaite construire un modèle qui reflète une intention
- 37. DDD MODÈLE - INTENTION #1 Carte des principaux monuments de Paris
- 38. DDD MODÈLE - INTENTION #2 Carte des moyens de transport de Paris
- 39. DDD UN MODÈLE UTILE ? Plusieurs cas d’utilisation au sein d’un même modèle
- 40. DDD RESTER PRAGMATIQUE ! ALL MODELS ARE WRONG, SOME ARE USEFULGeorges Box, statisticien
- 41. DDD ON CONTEXTUALISE POUR LEVER LES AMBIGUÏTÉS Nous fournissons un contexte pour chaque modèle
- 42. DDD INITIALISATION D’UN MODÈLE CLIENT
- 43. DDD UN MODÈLE CLIENT QUI SE COMPLEXIFIE AU FIL DU TEMPS
- 44. DDD UN MODÈLE CLIENT QUI SE COMPLEXIFIE AU FIL DU TEMPS
- 45. DDD SÉPARATION EN DES CONTEXTES SÉPARÉS Chaque contexte contient un modèle séparé
- 46. DDD CONTEXTUALISATION & RENOMNAGE Chaque contexte est une frontière linguistique afin d’enlever de l’ambiguïté
- 47. DDD MICROSERVICES Nous utilisons le DDD pour trouver la granularité des Microservices
- 48. DDD DOMAINE BANCAIRE - LES SERVICES ASSOCIÉS
- 49. DDD UNE APPLICATION : UNE COMPOSITION DE CONTEXTE
- 50. DDD APPLICATION DES MICROSERVICES CHEZ AMAZON
- 52. DDD DES PROPRIÉTÉS COMMUNES ▸ Maintenance dans le temps ▸ Des composants conçus indépendant du mécanisme de persistance ▸ Isolation des responsabilités ▸ logique métier ▸ infrastructure ▸ orchestration ▸ Facile à tester
- 53. DDD CLEAN ARCHITECTURE - LA LOGIQUE MÉTIER D’ABORD
- 54. DDD CLEAN ARCHITECTURE - LA COMPLEXITÉ ACCIDENTELLE EST RELAYÉE
- 55. DDD CLEAN ARCHITECTURE - SÉPARATION DE LA LOGIQUE D’UTILISATION
- 56. DDD CLEAN ARCHITECTURE - LES CONTROLLERS REST SONT DES CLIENTS
- 57. DDD CLEAN ARCHITECTURE - USECASE / USECASE HANDLER
- 58. DDD CLEAN ARCHITECTURE - CQS (COMMAND QUERY SEPARATION) Séparation des lectures et des écritures
- 59. DDD CLEAN ARCHITECTURE - CQS
- 60. DDD CLEAN ARCHITECTURE - MISE À PLAT
- 63. CODE MODELING
- 64. DDD DOMAIN MODELING - CODE MODELING
- 65. DDD UTILISER DES TERMES DU MÉTIER ANY FOOL CAN WRITE CODE THAT A COMPUTER CAN UNDERSTAND, GOOD PROGRAMMERS WRITE CODE THAT HUMANS CAN UNDERSTAND Matin Fowler
- 66. DDD VS DOMAIN MODEL DANS LE CODE : QUEL LANGUE ? Il faut préserver le langage métier du modèle Évite le coût de traduction !!
- 67. DDD DOCUMENTATION NATURELLE DE LA NATURE DES OBJETS Annotations fournies par un kernel DDD JAVA
- 68. DDD DOMAIN - DES OBJETS RICHES AU LIEU DE DAO JAVA TERME MÉTIER OPÉRATION MÉTIER
- 69. DDD DOMAIN - DES OBJETS RICHES AU LIEU DE DAO JAVA UN CONTRAT MÉTIER
- 70. DDD DOMAIN - ALIGNEMENT DU CODE ET DU MÉTIER LOGIQUE MÉTIER RICHE JAVA
- 71. DDD ON FAVORISE LES BONNES PRATIQUES IMMUABLE JAVA OBJET MÉTIER TYPÉ ENCAPSULATION DE L’ÉTAT PAS DE GETTER / SETTER
- 72. DDD ON FAVORISE LES BONNES PRATIQUES VALEUR TYPÉE OPÉRATION MÉTIER JAVA
- 73. DDD COMMAND HANDLER LOGIQUE D’ORCHESTRATION 1. CHARGEMENT DE L’ENTITÉ RACINE 2. MODIFICATION EN APPELANT L’OPÉRATION MÉTIER 3. MISE À JOUR DU REPOSITORY INTENTION MÉTIER JAVA MANIPULATION D’UNE ENTITÉ RACINE
- 74. DDD REST CONTROLLER JAVA OBJET D’EXPOSITION RATTACHÉ AU CAS D’UTILISATION CRÉATION D’UN OBJET COMMAND ET ENVOIE DANS UN BUS DE COMMAND DTO
- 76. DDD LE DDD INDUIT DES BONNES PRATIQUES POUR RÉSOUDRE DES PROBLÈMES ▸ Magic Number ▸ Duplications ▸ Primitive obsession ▸ Mixed Concerns ▸ Fuzzy Terminology
- 77. DDD LEGACY - TROUVER LES SEAMS
- 78. DDD LA SÉPARATION DES DEUX MONDES
- 79. DDD LEGACY - COHABITATION AVEC LE DDD Besoin d’une couche ACL (Anticorruption Layer)
- 80. DDDD DISTRIBUTED DOMAIN DRIVEN DESIGN CQRS Event Sourcing Event-Driven
- 81. DDD EVENT-DRIVEN - EMISSION D’ÉVÉNEMENTS SIGNIFICATIFS PUBLICATION ÉVÉNEMENT MÉTIER ACCÈS AU BUS D’ÉVÉNEMENT
- 82. DDD EVENT-DRIVEN - EMISSION D’ÉVÉNEMENTS SIGNIFICATIFS PUBLICATION ÉVÉNEMENT MÉTIER
- 83. DDD CQRS (COMMAND QUERY RESPONSABILITY SEGREGATION) PROJECTIONS
- 85. LE DDD, AU NIVEAU ENTREPRISE
- 86. DDD ATTENTION À LA SUR UTILISATION DU DDD
- 87. DDD CONTEXT MAP
- 88. DDD CONTEXT MAP & AUTONOMY CONTEXT
- 89. LE SOCLE
- 90. DDD SOCLE - MÉCANISME DE BUS Une mécanique de bus apporte une souplesse de connectivité APPORTE FLEXIBILITÉ
- 91. DDD SOCLE - COMMAND BUS & QUERY BUS Capacité de personaliser les intercepteurs en fonction des Command & Query
- 92. EN RÉSUMÉ DDD, LE BON RÉFLEXE
- 93. DDD APPRENDRE LE VOCABULAIRE DDD
- 94. DDD LE DDD, DES BONNES HABITUDES AVANT TOUT ! ▸ Être curieux du métier ▸ Multiplier les ateliers avec les personnes du métier ▸ Piloter vos modèles par les cas d’utilisation ▸ Ne pas se précipiter sur des architectures Microservices / CQRS / Event Sourcing sans une approche DDD