Anatomie d'un cas d'usage
Reprenons notre test
const booking = book(accomodation, tenant, stay);
expect(booking.status).toBe("confirmed");On dit que la fonction book() est un cas d'usage. Ou use-case.
Pourquoi ? En quoi est-ce important ?
Un cas d'usage est une commande qui donne de la valeur à notre logiciel.
Les commandes
Une commande est une fonction qui modifie l'état du système.
Alors elle mérite une vigilance particulière :
1) pour ne pas autoriser n'importe qui à faire des modifications de l'état du système
Exemple : un utilisateur non authentifié ne doit pas pouvoir faire de réservation.
2) pour ne pas conduire à un état incohérent du système
Exemple : un même hébergement ne peut pas être réservé par 2 personnes différentes à la même date.
Mais notre application ne comporte pas que ces commandes.
Les requêtes
Nous aurons contamment besoin de lire l'état du système. Sans le modifier.
Par exemple pour obtenir la liste de tous les hébergements disponibles à la location.
Les commandes et les requêtes ont des enjeu très différents.
| Enjeu | Commande | Requête | |
|---|---|---|---|
| Volume | Faible | Elevé | Beaucoup + de recherches que de réservations |
| Rapidité | Faible | Elévée | OK pour attendre 1 seconde pour traiter une commande. Mais pas pour afficher des résultats |
| Intégrité | Elevée | Aucune | Seule une commande peut altérer l'intégrité du système. Une requête est en lecture seule |
| Rejeu | Compliqué | Facile | Facile de rafraichir l'écran pour actualiser les données. Par contre, relancer une commande en cours risque de donner un résultat incertain. |
| Résultat | OK ou Erreur | Des données ou rien | |
| Bloquant | Oui | Non | Pendant l'exécution d'une commande, il faut bloquer d'autres modifications simultanées |
L'important pour une requête, c'est sa performance. Pouvoir obtenir tout ce dont on a besoin pour vite l'afficher à l'utilisateur.
Pour une commande, on veut de la fiabilité. Si elle prend 200ms de trop, l'utilisateur est OK pour attendre à condition que ce soit sûr.
Les commandes utilisent des requêtes. Avant de modifier l'état du système, elles ont forcément besoin de le lire pour déterminer si le changement est possible.
Mais rarement l'inverse.
Pourquoi cette distinction ?
Cette distinction nous guide sur les endroits du code sur lesquels porter nos efforts.
Un filtre d'affichage "savons et gels douche" qui bugge, c'est embêtant.
Une commande "Paiement" qui ne facture pas le bon montant, c'est catastrophique.
Explorons la façon de coder une commande.