Introduction au DDD
Nicolas Eeckeloo
Les phrases qu'on entend
- “J’en ai déjà entendu parlé … mais je ne vois pas trop ce que c’est”
- “Ca doit avoir un rapport avec le TDD.”
- “Hein ? T’as un problème avec la touche D !”
- “Le DDD, j’ai lu l’article Wikipédia, c’est de la merde”
Le DDD, ce n'est pas :
- une nouvelle technologie révolutionnaire
- une méthode miracle pour architecturer une application
- un outil à la mode qui va bientôt devenir obsolète
- des entités Doctrine sans les getters/setters
The heart of software is its ability to solve domain-related problems to its user
Eric Evans
Le DDD, c'est quoi ?
- une approche pour concevoir des logiciels de qualité
- des outils de conception pour atteindre les objectifs métiers
- développe la connaissance métier
- utilise la technologie pour créer de la valeur
- comprendre l'activité de votre entreprise afin de produire un langage commun
Pourquoi le Domain-Driven Design ?
-
un seul et unique langage
-
priorités logicielles alignées avec les priorités métier
-
apprentissage du métier par tous
-
contribution de tous à l'étude du métier
-
pas de traductions nécessaires entre les différentes parties prenantes
-
délivrer de la valeur de manière continue
-
un framework pour le strategic et tactical design
Ubiquitous Language
Adjective : Existing or being everywhere, especially at the same time; omnipresent.
[yoo-bik-wi-tuh s]
A language structured around the domain model and used by all team members to connect all the activities of the team with the software.
Eric Evans
Quand et où l'utiliser ?
- user stories
- réunions de projet
- emails
- planning
- documentation
- code source
Avantages
-
risques d’incompréhensions diminués
-
meilleure communication entre les parties prenantes du projet
-
connaissance du métier présent dans le code de manière explicite
-
code source plus facile à comprendre (meilleure maintenabilité et évolutivité du code)
Strategic vs Tactical Design
Strategic Design First
- plus axé sur le domaine et l'importance de la connaissance du domaine
- impossible d'atteindre l'objectif sans connaissance approfondie du domaine
- développeurs qui se focalisent à tort sur le Tactical Design
- les Stategical Patterns répondent davantage aux problématiques des projets complexes (Bounded Context, Context Mapping, Ubiquitous Language)
Sub-domains
- Generic Domain
- Supporting Domain
- Core Domain
Generic Domain
-
parties du système qui facilitent le métier, mais qui ne font pas partie du coeur de métier (abonnement, facturation)
-
concepts critiques mais qui ne font pas partie du coeur de métier
-
parties du métier qui peuvent éventuellement être outsourcées ou déléguées à une solution SaaS
Supporting Domain
-
parties du systèmes également nécessaires
-
fonctions de support directement relatives au métier principal
-
code de qualité et parfaitement architecturé pas nécessaire
-
possibilité d'outsourcer cette partie ou d'assigner des développeurs peu expérimentés
-
maintenir une séparation forte avec le coeur de métier (context mapping)
Core Domain
-
partie la plus critique et fondamentale pour le métier
-
constitue l'avantage concurrentiel et l'essence même du produit
-
domaine sur lequel vous souhaitez voir travailler les personnes les plus expérimentées
Core Domain
Selon Eric Evans, le core domain devrait fournir environ 20% de la valeur totale du produit, représenter environ 5% de la base de code, et correspondre à environ 80% de l'effort total.
Context Mapping
Behaviour Driven Development
BDD is the art of using examples in conversations to illustrate behaviour
Liz Keogh
By embedding Ubiquitous Language in your scenarios, your scenarios naturally become your domain model
Konstantin Kudryashov
Modelling by example
- la meilleure manière de comprendre le métier est de discuter autour d'exemples
- écrire des scénarios qui illustre des situations réelles
- écrire des scénarios qui utilisent l'ubiquitous language
- piloter le code par ces exemples
Event Storming
-
réunir les personnes qui ont des questions et celles qui ont des réponses
-
aborder tous les composants importants le plus tôt possible afin de découvrir les problèmes potentiels
-
toucher toutes les personnes concernées le plus tôt possible, en mettant à profit ce qui ressort des interactions entre chacune
Merci
Introduction au DDD
By Nicolas Eeckeloo
Introduction au DDD
- 1,319