Recommandé
Contenu connexe
Similaire à Domain_Driven_Design
Similaire à Domain_Driven_Design (20)
Plus de SpikeeLabs
Plus de SpikeeLabs (16)
Dernier
Dernier (8)
Domain_Driven_Design
- 3. DOMAIN-DRIVEN DESIGN Pas un Framework Pas une technique de code C’est une philosophie et une boite à outils
- 4. Le but de DDD c’est d'éviter ça ! DOMAIN-DRIVEN DESIGN « Ce que le client voulait vraiment » : http://www.projectcartoon.com/cartoon/2
- 5. « The blue book » « Tackling Complexity in the Heart of Software » Ecrit par Eric Evans en 2003 DOMAIN-DRIVEN DESIGN – LES ORIGINES
- 7. La Stratégie définit l’objectif Où on va ! La Tactique, c’est l’implémentation Comment on y va ! DDD – STRATÉGIE ET TACTIQUE
- 8. DDD – LES PATTERNS STRATÉGIQUES Les patterns stratégiques du Domain-Driven Design (tirés du livre « DDD Vite Fait »)
- 9. Le langage partagé permet de fournir un vocabulaire issu du métier qui est identique entre le métier et l'équipe technique. DDD – LANGAGE UBIQUITAIRE https://www.jpattonassociates.com/glad-we-all-agree-2/
- 10. DDD – LANGAGE UBIQUITAIRE Cependant un terme peut avoir plusieurs significations différentes en fonction du contexte: • Du côté de la comptabilité, un client c’est la personne qui paye les factures. • Pour le marketing, un client c’est la personne qu’il a au téléphone et qui utilise l’outil. • Chez les développeurs, un client, c’est une entreprise inscrite sur la plateforme qu’ils ont développée.
- 11. Un contexte borné représente une façon de voir le monde. 1 BC = 1 Base de code 1 BC = 1 Ubiquitous Language DDD – CONTEXTE BORNÉ
- 12. DDD – CONTEXTE BORNÉ https://martinfowler.com/bliki/BoundedContext.html
- 13. Core Domain Supporting Domain Generic Domain DDD – CONTEXTE BORNÉ
- 15. On utilise un ACL si on veut communiquer avec du code legacy sans corrompre nos contextes bornés. DDD – ANTI CORRUPTION LAYER
- 16. DDD – LES PATTERNS TACTIQUES Les patterns tactiques du Domain-Driven Design (tirés du livre « DDD Vite Fait »)
- 17. DDD – VALUE OBJECT
- 18. Les entités permettent de créer de l'identité, quelque chose d'unique, distinguable parmi d'autres éléments - c'est pourquoi elles ont souvent un ID unique. DDD – ENTITÉ
- 19. DDD – ET PLEIN D’AUTRES Aggregate Roots Services Repository Factory Architecture en couches
- 20. TALK DEVFEST NANTE [DevFest Nantes 2022] Bien se lancer dans le Domain Driven Design sans se tromper de combat
- 21. Rennes 35 Boulevard Solférino 35000 Rennes Paris 350 rue de Vaugirard 75015 Paris Nantes Whoorks Nantes Gare 17 Boulevard de Berlin 44000 Nantes + 33 2 30 96 21 60 www.spikeelabs.fr
Notes de l'éditeur
- il s’agit de représenter le métier directement dans le code. Plutôt que de coder le métier. on se base sur le métier pour assembler la solution que l’on apporte au business, autrement dit notre code. Ainsi, la structure, le nom des classes, des champs, les actions des fonctions : tout ceci doit refléter le métier.
- On a tous vu cette image Avec DDD, on livrera quelque chose qu’attend le client car on aura compris dès le début ce qu’il souhaitait.
- Il présente ce livre comme étant le fruit de 20 années de bonnes pratiques de développement tirées au sein de la communauté de la programmation orientée objet et du software craftsmanship.
- Avant de commencer à coder il faut voir où on va. Partant de ce principe, le DDD veut d’abord faire monter les équipes en compétence sur le domaine métier grâce à certains outils ou méthodes (les patterns stratégiques). Une fois que cette partie est totalement comprise, on essayera de retranscrire au mieux cette partie métier dans le code.
- Pour ce faire DDD fourni des patterns Stratégiques pour assister la modélisation
- Ce langage commun permet de mettre des mots précis sur le domaine d’expertise et de s’entendre sur les bons termes à utiliser lors des communications. Souvent les ambiguïtés et les incompréhensions entre le business et l’équipe de dev sont créées par le langage utilisé dans les communications. En utilisant l’Ubiquitous Language, on sait que tous les termes ne se valent pas.
- Tout le monde l'appelle client... Et potentiellement, ce ne sera pas la même personne.
- Le contexte borné est limité par son contexte métier. Par principe, tu ne devrais pas avoir besoin de partager du code entre tes contextes si jamais ils sont limités et clairement définis.
- Un bounded context contient du code qui doit rester à l’intérieur de ses propres frontières. Cela crée souvent de la duplication au lieu d’en supprimer mais c’est une bonne chose. Pour le service de vente le client n’a potentiellement pas la même adresse que le service de support. Un bounded context ne DOIT PAS en affecter un autre. Aussi avoir un peu de duplication pour protéger le contexte en cas d’évolution est une bonne chose.
- Core Domain : Le cœur de domaine, c'est le cœur du business. Support Domain : Pour les sous-domaines, ce sont les problèmes qui viennent avec notre problème principal. Generic Domain : Gestion des utilisateurs, autorisations, paiement, emails…
- Les Shared Kernel permettent de factoriser des entités appartenant à plusieurs contextes bornés. Chaque changement dans le noyau occasionne une communication des équipes sur les changements apportés Les éléments du noyau doivent être testés un maximum dans le noyau et en dehors. Car il s’agit là d’un point où potentiellement un commit peut tuer un bounded context.
- Les Shared Kernel permettent de factoriser des entités appartenant à plusieurs contextes bornés. Chaque changement dans le noyau occasionne une communication des équipes sur les changements apportés Les éléments du noyau doivent être testés un maximum dans le noyau et en dehors car il s’agit là d’un point où potentiellement un commit peut tuer un bounded context.
- Pour ce faire DDD fournit des patterns techniques pour l’implémentation.
- Les Value Objects simplifient le design, ils sont partageables, immuables, copiables, serializables... Ils ne doivent pas avoir de setter. Les avantages d’un objet-valeur : Découper les entités plus proprement Dégager de la complexité métier dans une classe dédiée Exprimer le domaine métier plus facilement Garder la complexité d’un objet à l’intérieur de ce dernier
- Les entités sont mutables.
- Des questions ?