Publié le 06/21/2017, rédigé par
Davy CLAISSE
Domain Driven Design
Introduction au DDD (Domain Driven Design)
Le Domain Driven Design est un concept énnoncé par Eric Evans en 2003 et qu'il est possible de reformuler et de synthétiser en l'expliquant en deux étapes : le constat et la réorganisation des interactions.
Le constat
- Une organisation fait collaborer différents acteurs dans le développement de ses produits.
- Les acteurs autour d'un même produit se partagent des rôles semblables ou distincts.
- Chacun de ses rôles implique souvent des connaissances spécifiques et un vocabulaire particulier à ce rôle, ce qui constitue un domaine d'expertise.
- La différence entre deux domaines d'expertises disjoints devant collaborer génère de la friction (problème de vocabulaire, prérequis manquant, connaissances non partagées, etc).
Il en ressort un triple problème :
- Le travail en équipe à l'intersection de deux rôles est difficile.
- Les incompréhensions sont à l'origine de produits ne répondant pas au besoin réel.
- La productivité est affectée négativement.
Réorganisation des interactions
L'idée est de rassembler tous les acteurs autour d'une même table pour qu'ils définissent ensemble :
- Un contexte représentant leur sujet de travail.
- Je connais les contraintes de l'autre.
- L'ensemble des activités de leur contexte de travail.
- Je comprends le travail de l'autre.
- L'ensemble des façons de faire et des usages de leur contexte de travail.
- Le comprends les méthodes de l'autre.
- un vocabulaire commun appelé ubiquity language.
- Je parle la langue de l'autre.
N.B : ce vocabulaire est un vocabulaire partagé par tous ce qui signifie qu'il est autant technique que métier.
Tout ceci constitue le Domain (mot anglais) de l'application développée.
Comment les équipes se serviront-elles de ce Domain ?
- La MOA pour exprimera ses besoins à travers le Domain.
- Les développeurs coderont en utilisant le Domain (noms de classes avec le vocabulaire, nom des méthodes avec les activités, etc).
- Les architectes documenteront leurs travaux à partir le Domain (eg. un composant = un usage).
- Les designers définiront des maquettes au moyen du Domain.
- Les procédures d'administration seront écrites dans le Domain.
On comprends donc que le design même de l'application sera affecté par le Domain définit et que les développements seront dirigés par ce domaine d'où l'appellation Domain Driven Design.
Sélection d'articles :
-
Créer un micro-service en deux minutes avec UndertowUndertow2017/09/29 -
Afficher un texte dans un input qui disparait dès la première frappe au clavierHTML 52017/05/28 -
Structure d'un composant AngularAngular 42017/05/25 -
Comment concaténer un fichier JS à ses dépendances ?Webpack2017/06/01 -
Comment utiliser les différents niveaux de logs ?Logs & Bonnes Pratiques2019/04/01 -
Comment manipuler des fichiers PDF en Java avec la librairie Apache PDFBox ?PDFBox2017/06/10 -
Tester du code javascript facilement avec Jasmine.jsJasmine.js2017/06/16