Appliquez le principe du Domain-Driven Design à votre application

Mettez à jour votre diagramme de cas d'utilisation

Le problème avec les clients, c'est qu'ils changent constamment d'avis. Nos bibliothécaires n'échappent pas à cette règle.

Après quelques échanges, vous vous rendez compte qu'ils ne sont pas 100 % satisfaits. Apparemment, quand un livre n'est pas disponible, les usagers se plaignent de devoir vérifier régulièrement s'il l'est à nouveau. Et même s'ils le cherchent depuis des semaines, il suffit que quelqu'un ait un peu de chance, et passe juste devant eux. Ce qui agace d'autant plus les bibliothécaires quand ce même titre est particulièrement demandé. Ils souhaiteraient donc augmenter l'amende pour les livres populaires rendus en retard et faire en sorte que les usagers puissent mettre un livre de côté.

Un petit conseil si vous voulez garder votre calme dans ce métier : autant vous y habituer tout de suite, les clients sont comme ça. Il y a toujours de nouveaux éléments à prendre en compte. Mais essayons de relativiser ; au final, il n'y a que deux nouvelles fonctionnalités à prendre en compte :

• mettre un livre de côté ;

• augmenter l'amende pour un livre populaire.

Concrètement, quelles sont les implications pour vous ? C'est simple : vous devez mettre à jour votre documentation !

Tout d'abord, il va falloir déterminer si vous avez affaire à un cas d'utilisation totalement nouveau ou à une modification d'un cas d'utilisation existant. L'idée de mettre un livre de côté n'est reliée à aucun cas d'utilisation précédent. Vous devez donc reprendre votre diagramme et y ajouter un ovale.

Vous avez vu comme c'est simple ? C'est bien là toute la puissance du Domain-Driven Design : sa capacité d'adaptation ! 😎

Mettez à jour votre diagramme de classes

À présent, nous devons créer une description du nouveau cas d'utilisation. Cela nous permettra de repérer s'il faut ajouter de nouvelles classes ou de nouveaux attributs. Voici la description du nouveau cas d'utilisation : 

• l'utilisateur recherche un livre ;

• le système affiche les informations relatives au livre :

  • notamment le fait qu'il est actuellement emprunté par un autre usager ;

• l'utilisateur sélectionne l'option Mettre de côté ;

• le programme demande les coordonnées de l'usager ;

• l'utilisateur saisit le nom de l'usager ou son identifiant à la bibliothèque ;

• le programme confirme l'existence de l'usager ;

• le programme ajoute l'identifiant de l'usager à la liste des exemplaires mis de côté du livre.

Les nouveaux noms ont été mis en gras. Vous pouvez créer un diagramme de classes pour montrer les  nouveaux concepts et ceux déjà en lien avec ce cas d'utilisation :

Intéressons-nous un peu au nouveau diagramme. 🧐 Les éléments suivants ont été ajoutés :

• une classe Liste des exemplaires mis de côté, qui est reliée à la classe Livre. Un livre ne peut figurer qu'une fois sur la liste des exemplaires mis de côté. Par contre, cette liste peut comporter de nombreux livres ;

• une relation entre la classe Usager et la classe Liste des exemplaires mis de côté. Un usager ne peut être qu'une fois sur la liste des exemplaires mis de côté. Par contre, cette dernière peut comporter de nombreux usagers ;

• des attributs pour la classe Usager : nom et prénom de l'usager, ainsi qu'un identifiant unique.

Eh bien, pas la peine de faire un travail supplémentaire pour ce cas-là, et de l'ajouter au diagramme : il s'agit juste d'une extension du cas d'utilisation "Infliger une amende aux usagers". En revanche, vous devrez ajouter une définition expliquant ce qu'est un livre populaire dans le modèle de domaine, car c'est un nouveau concept. Dans ce cas, ajoutez « Livre populaire » à la classe Livre :

Non, cela signifie simplement que le programme change de comportement, il s'adapte aux besoins de vos clients. Il est essentiel de tenir votre modèle à jour. Vous n'avez pas envie qu'un nouveau concept vous échappe. Si vous prenez la (très) mauvaise habitude de ne pas mettre à jour votre modèle, vous allez retomber dans l'approche « le programme d'abord, les besoins clients ensuite ».

Dès que de nouvelles idées sont lancées, il faut adapter votre modèle de domaine. Pour cela, il vous faudra souvent ajouter de nouvelles classes et de nouveaux attributs, ou encore déplacer un attribut d'une classe à une autre. 

👩‍🔬 Entraînez-vous ! 

Parfois, vous devez modifier votre documentation pour intégrer de nouvelles idées, et parfois non ! Dans notre exercice, je vais mettre votre capacité à prendre la bonne décision à rude épreuve, mais je suis sûre que vous allez très bien vous en tirer !

Au fil de vos discussions avec vos bibliothécaires, vous découvrez qu'un livre populaire est un livre qu'au moins trois usagers ont demandé de mettre de côté en une semaine. Alors, faut-il modifier votre documentation pour intégrer cette définition ? Ou bien ce n'est pas nécessaire ?

Nous avions déjà représenté le concept de livre populaire. La manière dont est déterminée sa popularité peut changer au fil du temps, mais l'idée de popularité ne change pas. Vous ne devez donc pas modifier votre diagramme !

Cela peut paraître compliqué, mais souvenez-vous que la logique métier ne doit pas figurer sur un diagramme de classes. Bien sûr, votre code devra parcourir la liste des livres mis de côté et déterminer si certains d'entre eux apparaissent au moins trois fois, mais comme il s'agit de logique métier, cela n'apparaît pas sur notre diagramme de classes.

En résumé

• Les diagrammes de cas d'utilisation et les diagrammes de classes s'adaptent aux besoins changeants des clients. 

• Quand un client demande des modifications, les étapes à suivre pour adapter le diagramme sont les suivantes :

  • créer les descriptions des nouveaux cas d'utilisation ;

  • répéter le processus de recherche des classes et des attributs ;

  • si nécessaire, modifier le modèle existant afin d'intégrer les nouvelles idées.

Dans le chapitre suivant, nous étudierons comment créer des catégories à partir de ces classes, et la manière de les mettre en œuvre dans le code.