Ça vous est sûrement déjà arrivé d'aller au restaurant avec quelqu'un qui passe commande, puis change d'avis. Et qui change encore sa commande avant que le serveur soit parti...
Eh bien, cela se produit tout le temps dans le développement d'applications. Ce n'est la faute de personne : les affaires sont les affaires, et elles évoluent vite. De nouvelles idées de fonctionnalités naissent, la législation évolue, ou alors les utilisateurs n'aiment pas la façon dont quelque chose fonctionne.
Pour être un développeur heureux, il faut être un développeur qui comprend que le changement fait partie intégrante du développement. Ça vous évitera quelques frustrations à chaque nouvelle demande de modification.
Identifiez les acteurs : les utilisateurs de l'application
Pour vous aider à comprendre d'où viennent toutes ces modifications, nous allons nous pencher sur les utilisateurs et leurs attentes. Votre objectif est de comprendre les besoins des utilisateurs, de leur point de vue, afin de pouvoir les retranscrire au mieux dans votre code.
Cernez les différents domaines grâce aux acteurs
Tout ce qui utilise votre application est considéré comme un acteur. Celui-ci demande à une fonctionnalité d'agir à sa place. Il s'agit généralement d'une personne, mais il peut également s'agir d'un autre programme, ou même d'un moment donné dans le temps.
Par exemple, si votre application de bibliothèque génère un bilan quotidien des livres empruntés. Ce type de bilan est souvent déclenché à minuit, ou quelques minutes plus tard. Le passage à minuit est donc ici un acteur, d'un point de vue conceptuel. 🤖
Comme les acteurs sont ceux qui déclenchent un événement dans l'application, ils ne font pas partie à proprement parler du domaine que vous créez. Ils ne sont donc pas modélisés de façon très détaillée, seules leurs interactions vous intéressent.
Un conducteur déclenche le freinage en appuyant sur le frein, mais il ne fait pas partie intégrante de la voiture.
Dans le Domain-Driven Design, les acteurs sont un bon moyen d'identifier les différents domaines. En effet, il est assez simple de distinguer leurs objectifs. Par exemple, imaginez un site web sur lequel vous achetez et vendez différents produits. Certains acteurs feront partie du même domaine, parce qu'ils partagent les mêmes objectifs : les clients qui achètent feront partie d'un domaine différent de celui des fournisseurs qui vendent. En cernant les objectifs des utilisateurs, cela vous permettra de mieux identifier les différents domaines
Priorisez
En outre, l'identification des acteurs est une étape essentielle du Domain-Driven Design, car ils permettent d'établir des priorités dans ce qui doit être créé.
La citation de George Orwell, dans La Ferme des animaux, est assez représentative ici :
« Tous les acteurs sont égaux, mais certains sont plus égaux que d'autres. »
Vous ne voulez pas gaspiller du temps (ni de l'argent 💸) sur une fonctionnalité qui ne concerne qu'un acteur peu important de votre programme !
Mais comment faire la différence entre acteurs prioritaires et acteurs secondaires ?
Eh bien, demandez-vous qui finance votre projet. 🤑
Ça paraît intéressé, mais en vérité il s'agit d'un facteur déterminant. Il faut penser stratégique : les acteurs prioritaires se situent là où vous identifiez les plus grandes retombées pour l'entreprise/le client.
Examinons à nouveau un site d'e-commerce/un entrepôt. Les acteurs prioritaires sont ceux qui effectuent des achats. Toutes les fonctionnalités qui leur permettent d'acheter plus facilement, ou davantage, figureront en tête de liste. En revanche, l'espace d'administration pour les salariés de l'entreprise qui effectuent de la maintenance paraît moins prioritaire.
Comment déterminer qui sont les acteurs dans votre système ? Vous l'avez deviné : en parlant aux clients !
Souvenez-vous de notre application pour la bibliothèque. Vous rencontrez deux des bibliothécaires pour comprendre leurs besoins. Ci-dessous, vous avez une retranscription de l'entretien. Voyez si vous pouvez identifier certains acteurs. Repérez les références aux personnes qui auraient besoin d'utiliser le système :
Développeur : Maintenant, je vais avoir besoin que vous m'expliquiez un peu ce que vous faites.
Bibliothécaire 1 : Est-ce qu'il faut être technique ? Parce que nous avons une base de données, nous savons nous en servir.
Développeur : Non, pas forcément. Expliquez-moi juste votre quotidien pour que je comprenne comment la solution que nous construisons doit vous aider. Par exemple, le matin, quelle est la première chose que vous faites ?
Bibliothécaire 1 : Prendre mon café. 🙃Non, généralement, le premier arrivé crée un rapport des livres en retard.
Bibliothécaire 2 : Ah oui surtout, parce que lorsqu'un livre est emprunté depuis trop longtemps, il faut qu'on secoue un peu l'usager.
Bibliothécaire 1 : Ça me faciliterait vraiment la vie si je pouvais cliquer, et avoir la liste par ordre de retard. Ce serait parfait si je pouvais sélectionner les noms, et envoyer un mail à tout le monde d'un coup, en un clic.
Bibliothécaire 2 : À vrai dire, ce serait encore mieux si on ne devait même pas s'en occuper. Le système saurait par lui-même quels livres sont en retard et empruntés par qui.
Bibliothécaire 1 : Très bonne idée. D'ailleurs, quand ils sont trop en retard, nous leur mettons une amende. Pour le moment, on leur envoie un mail d'avertissement tous les trois jours. Et au bout de la troisième fois, on commence à mettre des amendes de retard.
Bibliothécaire 2 : Parce que s'ils ne ramènent pas le livre, il faudra en acheter un en remplacement. C'est justement ce qu'on cherche à éviter parce que certains livres ne sont plus édités. Dans ce cas, c'est une vraie galère : il faut chercher dans d'autres bibliothèques, voir s'ils ont une copie...
Bibliothécaire 1 : Bref, il faut que le système nous aide à gérer les amendes. L'usager peut payer l'amende en ligne ou en personne, par carte de crédit ou en liquide. Mais bon, c'est quand même pas mal quand il vient en personne parce que ça nous permet de l'inciter à nous rendre notre livre.
Bibliothécaire 2 : Dans ce cas-là, on peut lui permettre de payer en ligne que s'il nous a rendu le livre.
Bibliothécaire 1 : Ça me paraît pas mal. 😊Je pense qu'on a fait le tour !
Quels utilisateurs avez-vous identifiés pour le moment ?
Pendant l'entretien, les bibliothécaires qui ont besoin d'utiliser le système parlent également des usagers qui interagiront avec ce dernier. Ce qui nous donne deux acteurs : les usagers et les bibliothécaires.
Pour créer le système, vous devez déterminer ce que ces acteurs essaient de faire.
Identifiez les cas d'utilisation ou use cases : ce que les acteurs essaient de faire
Alors, avez-vous essayé d'organiser un event storming avec vos proches dans le chapitre précédent ? Vous vous retrouvez sûrement confronté à beaucoup d'idées. Comment faire pour trier toutes ces informations et repérer ce qui est pertinent ? Une façon simple consiste à commencer par identifier les différents cas d’utilisation, ou use cases. Les cas d’utilisation correspondent à ce que les acteurs tentent d'effectuer.
Un exemple des chapitres précédents : le modèle de l'école. Différents cas d’utilisation peuvent être identifiés :
Noter les examens.
Enregistrer les absences.
Collecter les frais de cantine.
Payer l'enseignant.
Or, nous l'avons vu, créer une application en partant de la technique, ou par la logique ascendante, entraîne inévitablement des problèmes à long terme.
Attendez, je ne suis pas sûre que nous ayons tout pour concevoir une application, non ?
La voix de la sagesse 🤓! Il faut commencer par identifier le ou les objectifs que l'utilisateur (acteur) souhaite atteindre et, ensuite, remonter à l'interaction entre l'utilisateur et le programme, qui leur permet d'atteindre cet objectif.
Mais, pour le moment, concentrons-nous sur les objectifs.
Étape 1 : Comprenez les objectifs
Revenez en arrière et relisez la conversation entre la développeuse et les bibliothécaires. Mais cette fois, essayez de cerner les cas d'utilisation ; c'est-à-dire, les objectifs que les bibliothécaires cherchent à accomplir, pas tous les détails.
Allez-y, écrivez-les afin de pouvoir les comparer avec la réponse.
Avez-vous fini ?
Voici ce que vous devriez avoir trouvé :
Créer le rapport des livres en retard.
Infliger des amendes pour retard.
Acheter les livres en remplacement.
Recouvrer les amendes.
« Créer le rapport des livres en retard » ne comporte pas d'informations, mais, à ce stade, nous essayons seulement de savoir ce que les bibliothécaires veulent que le système fasse. Vous répondrez à la question "comment" plus tard.
Et si quelque chose m'échappe ?
Tout ce processus porte sur la collaboration. Vous aurez de nombreuses conversations, et vous risquez de rater un élément ici ou là. Mais vous aurez de nombreuses occasions de revenir et de combler les lacunes.
Étape 2 : Identifiez les interactions par les cas d’utilisation
Il est temps de se pencher un peu plus sur les détails cette fois-ci. 🔍
Une fois que vous avez défini le pourquoi d'un des cas d’utilisation, vous devez le relier aux interactions correspondantes. Vous pouvez les décrire de plusieurs manières, mais l'une d'entre elles consiste à répertorier tous les "va-et-vient" entre l'utilisateur et le programme.
Par exemple, prenons le cas d'utilisation « rechercher un livre ». Vous allez décomposer le scénario en commençant par l'utilisateur, puis en réfléchissant à la façon dont l'application réagit étape par étape :
L'utilisateur demande à rechercher un livre.
L'application affiche la page de recherche.
L'utilisateur saisit le nom de l'auteur.
L'application vérifie que le nom de l'auteur existe.
L'utilisateur saisit le titre du livre.
L'utilisateur demande l'exécution de la recherche.
L'application lance la recherche.
L'application affiche les résultats.
Et voilà ! Vous avez un cas d'utilisation simple. Vous commencez par un cas d'utilisation positif, qui est une séquence qui se termine bien.
Une minute ! Comment sont stockés les noms des auteurs ? Que se passe-t-il si le nom de l'auteur est introuvable ? Faisons-nous des suggestions ?
On verra ça en temps utile. Il y a encore beaucoup de détails à définir ! Vous développerez cette séquence de façon de plus en plus détaillée, si nécessaire. Alors oui, vous devrez finalement déterminer ce qui doit se passer si vous ne trouvez pas le nom d'un auteur.
Oui, mais c'est quand qu'on développe ?
Tout dépend de l'approche du projet (qui est indépendante du Domain-Driven Design et de la création des modèles de domaine). Il existe de nombreuses approches. À mesure que vous comprenez davantage de détails, vous pouvez utiliser l'approche agile, en décrivant plus de récits utilisateur (ou user stories) pour couvrir tous les différents parcours. Encore une fois, je vous conseille de prioriser ces différents scénarios en fonction de la probabilité qu'ils se produisent dans la réalité, et de l'importance du parcours.
Ainsi, dans l'exemple ci-dessus (l'utilisateur ne trouve pas le nom de l'auteur), vous pourriez avoir deux parcours alternatifs :
Afficher simplement « Il n'y a pas d'auteur portant ce nom. » (facile à mettre en œuvre, mais pas très utile).
Afficher des listes d'auteurs à l'orthographe similaire (pas facile à mettre en œuvre, mais très utile).
La décision concernant la solution à mettre en place, et quand le faire, est une décision davantage liée à la gestion de projet. Si vous êtes en entreprise, vous pouvez donc directement aller voir votre Product Owner ou Product Manager. Elle ne concerne pas le Domain-Driven Design.
Identifiez les entités : définissez les concepts de votre programme
Nous avons les acteurs, leurs objectifs, leurs interactions avec notre application ; il est maintenant temps de nous intéresser aux concepts mêmes de notre application. Pour cela, il faut analyser les interactions des récits utilisateur, et rechercher les idées pérennes, c'est-à-dire celles qui vont durer. Ces idées constituent les entités de votre modèle de domaine.
Houlà ! Comment on trouve ça ?
Pas de panique ! Reprenons l'exemple précédent.
Actuellement, il n'y a qu'un seul cas d'utilisation : rechercher un livre. C'est donc beaucoup plus simple à analyser (pfiou 😏).
Tentons de trouver quelques entités potentielles.
L'utilisateur demande à rechercher un livre.
Eh bien, un utilisateur est un élément importé pérenne, de même qu'un livre. Félicitations ! Vous avez trouvé vos deux premières entités. 🎉
Le programme affiche la page de recherche.
Même si on retrouve effectivement la notion de pérennité pour le programme, c'est lui que vous créez, et il n'est donc pas considéré comme une entité. La page de recherche est un détail de la mise en œuvre, elle est donc en dehors du domaine et n'est pas une entité.
L'utilisateur saisit le nom de l'auteur.
Les auteurs, en revanche, sont des idées importantes et en lien avec les livres. Les usagers et les bibliothécaires y font constamment référence. 🕵️♀️Ça ressemble à une entité !
Vous commencez à saisir l'idée ?
Eh bien, il faut continuer ce processus jusqu'à ce que vous ayez fait le tour des entités de votre application !
Si nous utilisons une approche orientée objet dans la mise en œuvre du code, les entités seront reliées à des classes et des objets.
Expérimentez par vous-même 👨🔬!
Maintenant que vous comprenez les acteurs, les cas d'utilisation et les entités, tentons d'identifier les entités pour vos bibliothécaires. Voici votre défi (si vous l'acceptez) :
Écrivez une description du cas d'utilisation « créer le rapport des livres en retard ». Identifiez les entités. Cliquez ici pour avoir un exemple !
Maintenant, essayez de trouver par vous-même les descriptions des trois derniers cas d'utilisation concernant les bibliothécaires :
Infliger des amendes pour retard.
Acheter les livres en remplacement.
Recouvrer les amendes.
Une fois que vous avez vos cas d'utilisation, exercez-vous également à identifier les entités !
En résumé
Une conversation avec des utilisateurs peut permettre d'identifier des acteurs et des cas d'utilisation :
Les acteurs sont les utilisateurs de votre application.
Les cas d'utilisation sont les objectifs que les acteurs veulent atteindre.
Rédigez les descriptions des cas d'utilisation de façon de plus en plus détaillée (interactions).
Déterminez les entités en analysant les descriptions des cas d'utilisation.
Maintenant, vous avez toutes les cartes en main pour tester vos connaissances dans le questionnaire de cette fin de partie ! Ça peut totalement arriver d'avoir des doutes, alors n'hésitez pas à jeter un œil sur les parties qui vous semblent moins bien acquises.
