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 :
-
Qu'est-ce qu'un mirror product (ou produit mirroir) ?Définition Financières2017/06/06 -
Qu'est-ce qu'un tableau ?Structure de données2017/07/25 -
Utiliser le FREE/BUSY dans Lightning.DAViCal2018/04/16 -
Désactiver le mode 'SSL Strict' et passer les proxys déchiffrant le traficYarn2017/05/29 -
Sérialiser et déserialiser un objet TypescriptTypescript2017/08/23 -
Automatiser le renouvellement d'un certificat Let's Encrypt avec Certbot (Debian)Let's Encrypt2017/11/21 -
Ajouter un composant HTML Input de type text à ma vueAngular 42017/08/19