Que ce soit un choix de votre part ou non, tous les projets d'application ont leur modèle. Bien sûr, si vous créez ce modèle volontairement, en l’occurrence, ici, un modèle de domaine, il sera beaucoup plus utile dans votre conception.
Alors, comment le Domain-Driven Design peut m’aider ?
Le Domain-Driven Design va vous aider à vous concentrer sur une réflexion par métier concernant le modèle. Ainsi, vous aurez toujours un point à partir duquel baser vos décisions.
L'approche Domain-Driven Design se focalise sur la compréhension d'un modèle de domaine en constante évolution.
L'objectif de l'utilisation du Domain-Driven Design est de construire un modèle qui fonctionne du début de la collaboration jusqu'au développement. Et pour y parvenir, vous devez discuter avec vos parties prenantes.
Recueillez vos informations auprès des différentes parties
Le Domain-Driven Design se concentre sur deux questions clés :
Pour qui suis-je en train de concevoir cette application ?
Que veulent-ils réaliser ?
Malheureusement, vous ne pouvez pas vous contenter de poser ces questions à vos clients par e-mail et attendre qu’ils vous donnent les bonnes réponses.
Mais au contraire, vous devez interpréter ce que vos clients vous disent grâce à des discussions. Et pour savoir le faire efficacement, vous devez vous entraîner.
Pas de panique, je serai là pour vous accompagner dans vos échanges. 🤗
Alors, au travail !
Votre mission, si vous l’acceptez, est de concevoir une application pour la bibliothèque publique de votre quartier. Maintenant, je suis sûre que vous avez deviné que vous devez parler à quelqu'un de la bibliothèque, mais qui ? 🧐
Étape 1 : Identifiez les utilisateurs de l'application
Réfléchissons. Au minimum, vous avez les usagers qui empruntent des livres et les bibliothécaires qui gèrent la bibliothèque. Vous avez peut-être également identifié d'autres parties prenantes importantes (comme les citoyens qui paient des impôts), mais cela me semble pas mal, dans un premier temps, de nous concentrer sur les deux premiers.
Étape 2 : Entamez la conversation
Allons d’abord parler aux usagers de notre bibliothèque. Voilà un exemple de conversation :
Vous (le développeur) : « Que souhaitez-vous pouvoir faire ? »
Usager : « Je souhaite pouvoir rechercher des livres. »
Bingo, vous avez besoin d'une fonctionnalité de recherche. Votre application est finie !
… Je plaisante ! Voici l'occasion de creuser un peu :
Vous : « Selon vous, comment faudrait-il procéder ? »
Usager : « Je devrais pouvoir faire des recherches par auteur, titre ou sujet, ou même grâce à l'ISBN. J’ai aussi besoin d’emprunter des livres. Et si un livre n'est pas disponible, je veux pouvoir le réserver et être informé quand je peux le retirer. »
Vous : « Comment voulez-vous être prévenu quand il sera disponible ?
Usager : « Par un e-mail, ou un SMS. Ou peut-être qu'il existe une application qui enverra des notifications sur mon téléphone. »
Bien, d'après cette conversation, que savez-vous sur les utilisateurs pour le moment ?
Ils souhaitent rechercher des livres.
Ils souhaitent emprunter des livres.
Ils souhaitent réserver des livres.
Ils souhaitent être informés quand un livre devient disponible.
Mais que ne devez-vous pas faire tout de suite ?
Commencer à créer une application de messagerie pour notifier les utilisateurs par e-mail de la disponibilité des livres.
Créer votre base de données pour suivre les auteurs, titres, sujets, etc.
Créer une application mobile qui enverra des notifications.
Eh bien non ! Vous plonger tête baissée là-dedans serait bien trop précipité : vous devez tout d'abord en apprendre davantage sur votre domaine. En omettant cette étape, ce serait le meilleur moyen de créer une application qui vous semble correspondre aux attentes des utilisateurs, mais qui serait différente de ce qu'ils avaient en tête.
C'est bien beau, j'ai ma première question, mais comment savoir quoi demander d'autre ?
Essayez de vous concentrer sur ce que l'utilisateur veut accomplir. Cela peut par exemple vous conduire à poser des questions complémentaires comme : « Si vous ne trouvez pas le livre que vous cherchez, que devrait-il se passer, selon vous ? ». Ils pourraient répondre : « Je voudrais que les autres livres du même auteur s'affichent » ou « Ça devrait me dire quand le livre sera à nouveau disponible ». Bien entendu, toutes les idées exprimées ne seront pas forcément exploitées, mais il est intéressant de savoir jusqu'à quel point un utilisateur peut souhaiter pousser une idée.
Étape 3 : Posez des questions complémentaires
Penchons-nous maintenant sur les bibliothécaires. Voici ce que l'entretien donne avec eux :
Bibliothécaire : « Les nouvelles ressources doivent être commandées à un fournisseur. »
Vous : « Qu'est-ce qu'une ressource, exactement ? »
Bibliothécaire : « Un livre. . . ou un magazine. . . oh, ou des DVD. »
Vous : « OK, et comment procédez-vous pour commander les ressources ? »
Bibliothécaire : « Pour les livres, nous commandons entre un exemplaire, pour une ressource normale, et douze, quand il s'agit d'un titre populaire. Pour commander, nous utilisons l'ISBN. »
Vous : « Donc, vous commandez 12 exemplaires des livres les plus populaires et un des livres moins populaires. Et vous avez besoin du numéro ISBN pour les commander. »
Bibliothécaire : « C'est bien ça. »
Vous : « Que devez-vous faire d'autre avec les ressources ? »
Bibliothécaire : « Nous devons remettre en stock les ressources quand un usager les rapporte, et nous devons contrôler qu'elles ne sont pas abîmées. En cas de détérioration, on donne une amende à l'usager et on commande un exemplaire de remplacement. »
Donc, après avoir lu ce magnifique entretien, qu'avez-vous appris cette fois-ci sur les bibliothécaires ?
Ils commandent des ressources (livres, magazines ou DVD).
Ils les remettent en stock quand les usagers les rapportent.
Ils contrôlent qu'elles ne sont pas abîmées.
Ils infligent des amendes aux usagers.
Toutes ces idées doivent être représentées dans la conception par Domain-Driven Design.
Appropriez-vous le langage du domaine
Vous souhaitez commencer à créer votre modèle, mais pour cela, il faut d'abord apprendre le langage adéquat. Parmi les termes utilisés par les bibliothécaires, figurent livres, usagers, détériorations et amendes. Il est primordial d'utiliser les mêmes termes dans votre domaine, même si un terme équivalent semblerait convenir. Par exemple, vous pourriez être tenté de dire utilisateur au lieu d'usager, qui est le terme utilisé par les bibliothécaires.
Vous devez utiliser leur langage.
Ce concept est essentiel en Domain-Driven Design : il faut toujours se baser sur un langage partagé. Et si quelqu'un utilise un mot qui n'appartient pas à votre terminologie commune, vous devez savoir ce qu'il veut dire. S'agit-il d'un synonyme (utilisateur) à un terme existant (usager) ? Si oui, tenez-vous-en à un seul terme (ici, usager). Sinon, cela risque de semer la confusion. Et s'il s'agit d'un nouveau concept, définissez-le et voyez où il se place dans le modèle.
Tout ceci conduit à la création de votre vocabulaire de domaine. On l'appelle en Domain-Driven Design le langage omniprésent (ou ubiquitous language) : un ensemble de termes qui ont la même signification pour tous les participants.
Comment élaborer ce langage ?
Notre langage partagé doit venir de ce qu'on appelle les "experts métiers". Ceux qui maîtrisent les logiques métier du produit sur lequel on va travailler.
Le langage sera ensuite partagé par les différentes parties prenantes, qu'il s'agisse des propriétaires de l'application, des utilisateurs, des développeurs, d'autres équipes de développeurs, de tout le monde. L'objectif est de se mettre d'accord sur la signification des principaux termes ou concepts.
Petit exercice : pouvez-vous trouver un exemple dans lequel une erreur de terme pourrait avoir des conséquences négatives ?
Voici un exemple simple : l'utilisation du mot « prochaine ». Vous conduisez pendant que je regarde le GPS. Il y a beaucoup d'intersections dans la rue. Alors que vous approchez de l'une d'elles, je vous dis : « Tournez à droite à la prochaine intersection ! ». Est-ce que je veux dire, celle dont nous sommes très proches ou celle qui vient ensuite ? Si j'utilise « prochaine » d'une façon et que vous pensez à l'autre, bonjour la frustration. 🙈
Que faire quand ce genre de chose se produit sur un projet ?
La meilleure manière de résoudre ce genre de problème est de se réunir et de discuter de la signification du terme. Vous pouvez vous tromper, ça arrive. Ce qui est important, c'est d'identifier les différentes significations et de bien se mettre d'accord.
Vous vous demandez peut-être jusqu'où vous pouvez aller par rapport à ce fameux langage omniprésent. Croyez-moi : plus vous allez loin, mieux c'est.
Souvenez-vous. Dans notre discussion avec les bibliothécaires, ils avaient parlé de remplacer les livres abîmés. Si vous deviez déployer une fonctionnalité permettant de gérer ce concept, comment appeler la fonction correspondante ? Tout simplement, « remplacer le livre abîmé ».
Mais, et si mon langage de programmation ne prend pas en charge les espaces dans les fonctions ?
Bon oui, OK il suffit de faire RemplacerLivreAbîmé() en code ; mais pour le moment, restons à un niveau conceptuel. Mais gardez bien à l'esprit, quand vous écrivez votre code, qu'il vous faut utiliser le langage du domaine :
Class Livre {
String titre;
String nomdAuteur;
double ISBN;
};Vous l'avez compris : le plus efficace pour aller plus dans votre modèle est par la communication. À chaque fois que vous discutez d'un aspect du programme, vous devez vous habituer à utiliser autant que possible le langage partagé. Et avant même que vous posiez la question : oui, y compris entre développeurs. 👩💻👨💻
Mais est-ce que j'ai le droit d'utiliser des termes techniques quand j'échange avec des développeurs, et uniquement avec eux ?
Oui, bien sûr. Rassurez-vous, je ne vais pas censurer tous vos échanges. Et de toute manière, l'application doit bien être créée à un moment, n'est-ce pas ? Quelqu'un va bien devoir dire « requête SQL », ou « endpoint ». Mais s'il existe un terme spécifique dans le langage partagé pour représenter une idée, utilisez-le autant que possible.
Ajustez votre modèle à la bonne échelle
Vous vous souvenez, dans le chapitre précédent, quand je vous ai dit que les modèles mettent en avant les éléments clés ? Paul Valéry disait :
« Le simple est toujours faux. Ce qui ne l'est pas est inutilisable. »
Dans un modèle de domaine, le juste équilibre consiste à créer un modèle qui donne les informations nécessaires sans s'encombrer de détails inutiles.
Nouvel exercice pour vous. Je veux que vous pensiez à une carte.
La carte est un modèle. Elle montre les éléments importants, comme les contours de l'île, un lac, mais pas l'emplacement de chaque arbre, grain de sable ou des crocodiles.
Si l'échelle utilisée était de 1 pour 1, il s'agirait d'une reproduction (imaginez-vous en train d'essayer de replier une carte grandeur nature 🤦♀️). Dans ce cas, votre modèle/carte n'aurait pas d'utilité et vous pourriez tout aussi bien vous appuyer sur la réalité. L'utilité d'une carte est donc de représenter uniquement les éléments importants pour se déplacer.
C'est la même chose pour le développement de logiciels. Vous voulez modéliser les idées importantes, mais vous n'avez pas besoin de tous les détails.
Mais alors, comment savoir si je rentre trop dans les détails ?
La réponse est simple : quand votre client commence à somnoler 🙊.
Je vous taquine. Pour partir d'un exemple concret, revenons à notre bibliothèque. Si vous parlez de livre, d'ISBN, de nom d'auteur dans votre domaine de la bibliothèque, ça me semble tout à fait approprié.
Mais si vous commencez à parler de chaînes et de tri par insertion pour la recherche par auteur, ou de protocole SMTP pour l'envoi des notifications par mail, c'est aller trop loin. Les clients (bibliothécaires) n'ont aucune idée de ce qu'est un tri par insertion, et ce n'est pas ce qui les intéresse : c'est un détail relatif à la mise en œuvre. Il n'a donc pas sa place dans notre modèle.
Faites l'expérience par vous-même !
Choisissez un ami ou un membre de votre famille et dites-lui que vous vous entraînez à concevoir une application pour des professionnels. Demandez-lui quelle solution il aimerait avoir pour son travail, ou ce qu'il aimerait améliorer dans son système actuel. En discutant et en posant des questions, identifiez :
Pour qui est le système.
Ce que l'utilisateur veut réaliser.
Le langage partagé dont vous avez besoin.
Pour le moment, contentez-vous de noter ces éléments sous la forme d'une liste. Cette base sera très utile pour les étapes suivantes !
En résumé !
Vous avez vu que vous devez résister à la tentation d'écrire votre code immédiatement. Pour cela, vous devez notamment :
Collaborer avec les utilisateurs en discutant avec eux.
Créer un modèle des concepts et termes importants sur lesquels toutes les parties prenantes pourront se mettre d'accord.
Convenir d'un langage partagé commun qui devra être utilisé dans les conversations et jusque dans le code.
Dans le prochain chapitre, vous apprendrez comment l'application est censée fonctionner, du point de vue des différentes parties. Pour cela, nous apprendrons une technique appelée « event storming ».
