TLDR: DDD c’est bien. On vous explique une partie de la théorie, et on vous donne un exemple !
Tout part d’une conversation
Pour notre présentation nous prendrons Alice et Bob.
Bob est responsable marketing d’une société de service.
Bob cherche à améliorer la visibilité de l’entreprise auprès des talents et potentiels clients.
En regardant les sujets à la mode, le sujet Domain Driven Design sort du lot.
Alice est développeur.
Alice a déjà fait des projets en suivant les principes et les patrons de conception (souvent appelé design pattern) proposés par Eric Evans dans: « Domain-Driven Design: Tackling Complexity in the Heart of Software ».
Naturellement Bob va voir Alice :
(Bob): ça serait bien de faire un article sur « Domain Driven Design », les tests fonctionnels et « Qu’est-ce que le modèle MVC, à quoi sert-il ? »
(Alice): Aucun rapport entre MVC, les tests fonctionnels et DDD.
(Bob): Je ne m’y connais pas en DDD. Par contre, tu prends certains de nos concurrents, ils publient massivement sur le sujet
(Alice): c’est dommage que tu ne connaisses pas grand chose en DDD vu que tu conduis le projet de refonte du site.
(Bob): Je suis métier pas fonctionnel. Chacun son métier ?
(Alice): justement le DDD ça concerne le métier ?
(Alice): C’est parti !
De quoi parle DDD ?
Du métier ! enfin, du domaine. Bref c’est la même chose
L’idée est assez simple : Une solution logicielle répond à un besoin métier. Donc pour construire le logiciel, il faut s’appuyer sur le métier.
Pfiou je suis fatigué
Jusque là pas de soucis. Mais on fait comment ??
C’est là que ça se complique et que Eric Evans et ses copains interviennent et boom des millions de ressources disponibles.
Essai de définition de DDD:
- Approche de développement logiciel centrée sur le métier (domaine).
- Qui permet d’aligner les intervenants sur le vocabulaire et les concepts métiers (langage commun).
- Et propose des patrons de conception (design pattern) pour l’implémentation de domaines métiers complexes.
En résumé : limiter l’écart entre la réalité du métier et son implémentation avec la conception pilotée par le domaine.
Quand on regarde la représentation classique d'une architecture ddd , on se rend compte que c’est pas évident :
Surtout que le livre d’Eric Evans fait 500 pages et c’est bien mieux écrit que cet article.
On va essayer de paraphraser.
La définition du domaine
- L’application s’inscrit dans un contexte métier que l’on appelle « Core Domain ».
- Pour décliner « Core Domain » on découpe le métier en contextes indépendants nommés « Bounded Context ».
- Le nommage de tous les éléments du métier et des contextes sont regroupés dans « Ubiquitous Language ».
- La cohérence des « Bounded Context » est garantie par la « Context Map ».
Et la définition de tout ça c’est le travail du métier ! mais pas seulement.
Dans la vraie vie, structurer un domaine (métier) c’est pas facile, surtout quand on n’a jamais fait l’exercice.
On va laisser la partie « Comment je définis mon domaine ? » à un prochain article.
L’implémentation du domaine
Maintenant comment traduit-on le domaine en code durant l’implémentation ? Le design de l’application se fait en prenant le métier et en apportant une réponse technique.
Le Domain-Driven Design définit :
- Une Entity comme étant une « ressource » identifiable par un identifiant: la modification d’une Entity ne change pas son identification.
- Un Value Object comme étant une « ressource » identifiable par sa valeur: la modification d’un Value Object change son identification
- Un Domain Event comme étant l’expression d’un changement d’état.
- Un Aggregate comme étant un regroupement d’Entity et de Value Object partageant un objectif et des règles métier afin d’encapsuler leur cohésion.
La définition de ces objets se fait conjointement entre le métier et la technique.
Avec un exemple c’est mieux
Imaginons une solution de gestion des ressources d’une ESN (version volontairement minimaliste) permettant de gérer les services recrutement, rh et commerce.
Le core domain est donc le métier de l’ESN et ses règles de gestion, ses invariants.
Dans notre exemple, on définit des bounded context calqués sur les services de l’entreprise. (il est possible de découper autrement)
Les services RH, recrutement et commerce sont donc des bounded context.
Au sein du service de recrutement on parle de candidats.
Au sein du service RH on parle de collaborateurs.
Au sein du service commerce on parle de profils.
Dans cet exemple « candidats », « collaborateurs » et « profils » concernent des personnes. Seulement en fonction du contexte le vocabulaire ainsi que le cycle de vie des entités ne sont pas les mêmes pour :
- un candidat, le recrutement va s’intéresser aux expériences passées et aux compétences.
- un collaborateur, le service RH va s’intéresser aux informations civiles et aux compétences pour suivre la formation.
- un profil, le commerce va s’intéresser aux compétences et à la disponibilité.
On pourra décliner pour :
- le bounded context recrutement un agrégat « Candidat » composé d’une entité « Expérience » et d’un value object « Compétence ».
- le bounded context RH un agrégat « Collaborateur » composé d’une entité « InformationsCiviles » et d’un value object « Compétence ».
- le bounded context recrutement un agrégat « Profil » composé d’une entité « Disponibilités » et d’un value object « Compétence ».
Notes: Le terme compétence est défini dans 3 bounded contexts différents mais ne représente pas la même chose, ça dépend du contexte ? Dans une approche Domain-Driven Design on analyserait la pertinence du nommage compétence en fonction du contexte et définirait les informations nécessaires à leur usage.
Coté événement du domaine imaginons :
- Le changement de statut marital d’un collaborateur dans le contexte RH.
- L’embauche d’un candidat dans le contexte recrutement.
- Le changement de disponibilité d’un profil dans le contexte commerce.
Pour finir nous aurons donc l’ubiquitous language suivant:
Dans le contexte RH :
un collaborateur a des informations civiles et des compétences.
un collaborateur change son statut marital
Dans le contexte recrutement :
un candidat a des expériences et des compétences.
on embauche un candidat.
Dans le contexte commerce :
un profil a des disponibilités et des compétences.
un profil change de disponibilité
L’implémentation de ce domaine se ferait de la manière la plus directe possible en faisant abstraction des contraintes techniques (on parle de layered architecture).
namespace RH {
class Collaborateur {
IEnumerable<RH.Competence> Competences { get; }
RH.InformationCivile InformationCivile { get; }
void ChangeStatutMarital(StatutMarital statutMarital) {
/* validation des règles métier + stockage de l'information */
InformationCivile.StatutMarital = statutMarital;
EmetEvenement(CollaborateurAChangeDeStatusMarital());
}
}
}
namespace Recrutement {
class Candidat {
IEnumerable<Recrutement.Competence> Competences { get; }
IEnumerable<Recrutement.Experience> Experiences { get; }
void Embauche() {
/* validation des règles métier + stockage de l'information */
EmetEvenement(CandidatEmbauche());
}
}
}
namespace Commerce {
class Profil {
IEnumerable<Commerce.Competence> Competences { get; }
Commerce.Disponibilite Disponibilite { get; }
void ChangeDisponibilite(Commerce.Disponibilite disponibilite) {
/* validation des règles métier + stockage de l'information */
Disponibilite = disponibilite;
EmetEvenement(ProfilAChangeDeDisponibilite());
}
}
}
Conclusion
Domain Driven Design est une approche qui permet au métier de mieux définir ses cas d’usages et problématiques et aux développeurs de construire une solution répondant à ces besoins.
Domain-Driven Design implique un investissement fort en ressources et en énergie de la part de toutes les parties prenantes du projet.
De nombreuses ressources sont disponibles via votre moteur de recherche (c’est pas loin).
Voici quelques ressources pour commencer:
Retour aux articles