Contenu connexe
DDD Introduction
- 1. DOMAIN DRIVEN DESIGN ONY VA EN 2019 !! Grégory BOISSINOT Passionate DDD Practitioner
- 2.
- 3. DOMAIN DRIVEN DESIGNApprochede 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 (POURNOUS 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 Despatterns, 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 POURLES ÉQUIPES PROJETS
- 9. DDD UNE BASE DECODE SOURCE MAÎTRISÉE Sans le DDD Avec le DDD
- 10.
- 11. DDD ON CHERCHE D’ABORDÀ RÉSOUDRE DES PROBLÈMES MÉTIER
- 12. DDD LE CONTEXTE ESTROI ! ▸ 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 !! DESCRISES À 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
- 15.
- 16.
- 17. DDD L’EXTRACTION DE L’ESSENCEMÉTIER - LE PRINCIPE KUVINGS
- 18. DDD L’EXISTANT “ Ce qu’onsait “ “ Ce qu’on a besoin d’apprendre “
- 19. DDD L’ART DE LACONNAISSANCE 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 - ATELIERSDE 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 ENPRATIQUE ▸ 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
- 30.
- 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 LESSPÉCIFICATIONS
- 35.
- 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 ! ALLMODELS ARE WRONG, SOME ARE USEFULGeorges Box, statisticien
- 41. DDD ON CONTEXTUALISE POURLEVER LES AMBIGUÏTÉS Nous fournissons un contexte pour chaque modèle
- 42.
- 43. DDD UN MODÈLE CLIENTQUI SE COMPLEXIFIE AU FIL DU TEMPS
- 44. DDD UN MODÈLE CLIENTQUI SE COMPLEXIFIE AU FIL DU TEMPS
- 45. DDD SÉPARATION EN DESCONTEXTES SÉPARÉS Chaque contexte contient un modèle séparé
- 46. DDD CONTEXTUALISATION & RENOMNAGE Chaquecontexte est une frontière linguistique afin d’enlever de l’ambiguïté
- 47. DDD MICROSERVICES Nous utilisons leDDD 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 MICROSERVICESCHEZ AMAZON
- 51.
- 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.
- 60. DDD CLEAN ARCHITECTURE -MISE À PLAT
- 61.
- 62.
- 63.
- 64. DDD DOMAIN MODELING -CODE MODELING
- 65. DDD UTILISER DES TERMESDU 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 DANSLE CODE : QUEL LANGUE ? Il faut préserver le langage métier du modèle Évite le coût de traduction !!
- 67. DDD DOCUMENTATION NATURELLE DELA NATURE DES OBJETS Annotations fournies par un kernel DDD JAVA
- 68. DDD DOMAIN - DESOBJETS RICHES AU LIEU DE DAO JAVA TERME MÉTIER OPÉRATION MÉTIER
- 69. DDD DOMAIN - DESOBJETS RICHES AU LIEU DE DAO JAVA UN CONTRAT MÉTIER
- 70. DDD DOMAIN - ALIGNEMENTDU CODE ET DU MÉTIER LOGIQUE MÉTIER RICHE JAVA
- 71. DDD ON FAVORISE LESBONNES PRATIQUES IMMUABLE JAVA OBJET MÉTIER TYPÉ ENCAPSULATION DE L’ÉTAT PAS DE GETTER / SETTER
- 72. DDD ON FAVORISE LESBONNES 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
- 75.
- 76. DDD LE DDD INDUITDES BONNES PRATIQUES POUR RÉSOUDRE DES PROBLÈMES ▸ Magic Number ▸ Duplications ▸ Primitive obsession ▸ Mixed Concerns ▸ Fuzzy Terminology
- 77. DDD LEGACY - TROUVERLES SEAMS
- 78. DDD LA SÉPARATION DESDEUX MONDES
- 79. DDD LEGACY - COHABITATIONAVEC LE DDD Besoin d’une couche ACL (Anticorruption Layer)
- 80. DDDD DISTRIBUTED DOMAIN DRIVENDESIGN CQRS Event Sourcing Event-Driven
- 81. DDD EVENT-DRIVEN - EMISSIOND’ÉVÉNEMENTS SIGNIFICATIFS PUBLICATION ÉVÉNEMENT MÉTIER ACCÈS AU BUS D’ÉVÉNEMENT
- 82. DDD EVENT-DRIVEN - EMISSIOND’ÉVÉNEMENTS SIGNIFICATIFS PUBLICATION ÉVÉNEMENT MÉTIER
- 83. DDD CQRS (COMMAND QUERYRESPONSABILITY SEGREGATION) PROJECTIONS
- 84.
- 85. LE DDD, AUNIVEAU ENTREPRISE
- 86. DDD ATTENTION À LASUR UTILISATION DU DDD
- 87.
- 88. DDD CONTEXT MAP &AUTONOMY CONTEXT
- 89.
- 90. DDD SOCLE - MÉCANISMEDE BUS Une mécanique de bus apporte une souplesse de connectivité APPORTE FLEXIBILITÉ
- 91. DDD SOCLE - COMMANDBUS & QUERY BUS Capacité de personaliser les intercepteurs en fonction des Command & Query
- 92. EN RÉSUMÉ DDD, LEBON RÉFLEXE
- 93.
- 94. DDD LE DDD, DESBONNES 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