Ensemble, nous avons pris le temps de créer un modèle de domaine, utile et compréhensible pour toutes les personnes concernées, parties prenantes et développeurs compris. Il serait dommage de gâcher tous ces efforts en implémentant un programme qui n'utiliserait pas ce travail. Voici quelques lignes directrices à garder à l'esprit lorsque vous implémentez votre application.
Implémentez votre modèle de domaine
Une fois que vous avez un modèle de domaine, vous avez une meilleure vue d'ensemble de votre application. Il est donc plus aisé de prendre des décisions importantes en ce qui concerne l'implémentation ! Voici les étapes à suivre pour implémenter votre domaine.
1- Prêtez attention aux frontières
Il est possible d'avoir plusieurs contextes délimités (bounded contexts) dans un domaine. Dans le système de la bibliothèque, un ensemble de fonctionnalités est utilisé par les bibliothécaires et un autre par les usagers. Ces deux contextes délimités sont englobés dans un seul et même domaine.
En quoi cela a un impact sur l'implémentation ?
Vous allez voir qu'il est très important de prendre ces distinctions en compte.
Prenons un autre exemple : imaginez que vous avez été recruté comme développeur par le service informatique. On vous y voit comme quelqu'un qui a des compétences en programmation. Vous faites également partie de l'entreprise : le service des ressources humaines vous connaît donc également. Mais pour eux, vous représentez un salaire, des avantages et quelqu'un qui doit être invité à la fête de fin d'année de l'entreprise.
S'il fallait vous implémenter, vous seriez un concept différent dans chacun de ces services, bien que vous soyez une seule et même personne. Il y aurait des limites claires. Le service RH ne va pas vous attribuer un projet de codage, et le service informatique ne va pas vous accorder des jours de congé supplémentaires lors de votre entretien annuel. Ces différents contextes auront une incidence sur la façon dont vous implémenterez le concept de vous dans le programme.
2- Définissez des entités pour représenter des objets uniques
Il y a quelques chapitres de cela, je vous disais qu'une entité se reconnaissait par son caractère unique. Vous vous rappelez ? Cela mérite d'être répété, car c'est important : il s'agit d'éléments qui ont une identité de manière durable, peu importe leur état.
Pour revenir à notre exemple, vous seriez une entité dans l'entreprise qui vous a recruté. Même si vous changez certains de vos attributs (nom, couleur de cheveux, salaire, poste), vous restez une entité unique. Il faut garder cela à l'esprit lors de l'implémentation !
Les objets entités sont en général utilisés par plusieurs cas d'utilisation. C'est pour cela qu'ils sont habituellement enregistrés dans une sorte de système de stockage persistant (comme une base de données). 🗄
Dans notre application pour la bibliothèque, les comptes usagers et les livres sont des entités. En définissant ces éléments dans votre modèle, il vous sera beaucoup plus facile de faire les bons choix en matière d'implémentation.
3- Identifiez les objets valeurs dans votre modèle
Intéressons-nous maintenant aux éléments qui changent au fil du temps, et qui ne sont pas uniques. Il s'agit d'objets valeurs (value object). C'est le cas, par exemple, de l'amende pour un livre en retard.
Si les bibliothécaires décident d'augmenter le montant de l'amende quand le livre rendu est abîmé, il suffit de remplacer l'objet valeur représentant l'amende initiale par un nouveau. Autre cas : si vous devez représenter l'amende dans une autre devise. Vous devriez remplacer l'objet valeur de l'amende (Euros) par un autre (Dollars). L'objet initial (Euros) n'aurait plus aucune signification/utilité pour vous.
Autrement dit, un objet valeur est destiné à représenter une valeur. Si cette valeur n'est plus nécessaire, l'objet est supprimé et remplacé par un autre. Les objets valeurs sont habituellement créés uniquement pour faciliter l'exécution d'un seul cas d'utilisation. À la différence des entités, ils ne sont pas conservés dans le stockage de données, dans la mesure où ils ne sont nécessaires que brièvement. Dans l'exemple ci-dessus, l'amende est probablement calculée à partir du nombre de jours de retard. Il est inutile de conserver un objet et de le mettre à jour tous les jours. Mais il est nécessaire, au moins brièvement, pour calculer l'amende.
Profitons en pour faire une petite parenthèse.
Aujourd'hui, la data constitue une véritable mine d'or. Dans notre cas, il est probablement intéressant de savoir quels livres entraînent le plus d'amendes, ou de connaître le code postal des usagers qui rendent les livres dans les temps. Même si en général nous ne conservons pas l'objet valeur, certains programmes vont au contraire sauvegarder ce type d'informations, afin de comprendre toutes ces données.
Mais l'analyse de données pourrait clairement faire l'objet d'un cours à part entière, donc fermons la parenthèse.
4- Identifiez les objets d'agrégation
Pour terminer, vous avez besoin d'objets pour maintenir l'équilibre du système. Tous ces objets entités et valeurs qui circulent sont habituellement reliés d'une façon ou d'une autre.
C'est ici que les objets agrégats interviennent. Ils regroupent des objets valeurs et entités qui vont de pair en un tout unique, de telle sorte que vous pouvez les gérer comme s'il s'agissait d'un seul concept. Prenons comme exemple une liste de livres en retard :
Tout d'abord, vous avez les usagers (entités) qui n'ont pas rendu leurs livres. Ensuite, vous avez les livres (entités). Puis vous avez l'amende (valeur) qu'ils doivent payer. Vous devez rassembler tous ces éléments dans une seule et même idée.
Pour cela, il suffit d'introduire l'objet agrégat « livre en retard ». Notez qu'il a une relation de type « 1 » avec tous les éléments qui s'y rattachent. Ce n'est pas systématique pour un agrégat, mais c'est courant.
Découvrez la prochaine étape d'implémentation
Maintenant que vous avez vos contextes délimités, vos entités, vos objets valeurs et vos agrégats, vous pouvez passer au code. Mais, maintenant, vous avez une longueur d'avance dans la création de votre application. Dans la mesure où vous avez défini tous ces éléments, vous devriez avoir une idée claire de ce que fait et représente chaque objet, et cela vous permettra d'affronter sans soucis la complexité d'un système complet.
Dans notre programme pour la bibliothèque, vous n'avez vu que la partie émergée de l'iceberg de ce qu'est un modèle de domaine et de ce que le Domain-Driven Design apporte.
Vous n'avez qu'un seul domaine (l'application de la bibliothèque) et deux contextes délimités (le côté bibliothécaires et le côté usagers). En outre, chacun n'est composé que de quelques idées (usager, livre, etc.). Mais cela sera suffisant pour organiser votre processus de réflexion avant de coder. Lorsque vous commencez à travailler sur des programmes conséquents, à l'échelle d'une entreprise ou entre différentes entreprises, il est crucial de comprendre et de diviser les domaines pour créer des programmes qui seront facilement compréhensibles et modifiables.
Pour aller plus loin
Comme je vous le disais, vous avez fait votre première approche du DDD, félicitations à vous. Mais peut-être souhaitez-vous aller plus loin.
L'étude des livres existant en la matière peut vous mettre sur la bonne voie pour devenir un expert du DDD.
Pour les anglophones, je peux vous conseiller la lecture de l'excellent livre à l'origine de tout cela : Domain-Driven Design: Tackling Complexity in the Heart of Software de Eric Evans. Il existe également Domain-Driven Design vite fait en français ( 🐓), de Abel Avram & Floyd Marinescu, traduit par Guillaume Lebur.
Mais rien de tel que la pratique. Appliquez vos connaissances à votre vie de développeur de tous les jours. Comprenez pourquoi un concept s'applique bien à votre cas réel, et parfois moins bien. Échangez avec d'autres développeurs sur leurs modèles de domaine. Un nouveau monde s'ouvre à vous. 🤩
En résumé
Nous avons repéré les éléments clés à identifier une fois que vous avez terminé votre modèle de domaine :
les entités qui sont uniques dans le système ;
les objets valeurs qui n'ont pas de caractère unique ;
les agrégats qui regroupent une entité et un objet valeur, pour finaliser un cas d'utilisation ;
en outre, lors de l'implémentation vous devez repérer les contextes délimités, afin de coder votre solution d'une façon logique.
Dans le chapitre suivant, nous passerons en revue ce que vous avez appris dans ce cours. Un bon moyen de vous rafraîchir la mémoire, avant de tester vos connaissances dans le questionnaire de fin de partie !
