Anatomie d'un cas d'usage
Reprenons notre test
const booking = book(accommodation, 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 constamment 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 enjeux très différents.
| Enjeu | Commande | Requête | Pourquoi |
|---|---|---|---|
| Volume | Faible | Élevé | Beaucoup plus de recherches que de réservations |
| Exigence de rapidité | Faible | Élevée | On accepte d'attendre une seconde pour traiter une commande. Pas pour afficher des résultats |
| Intégrité | Élevée | Aucune | Seule une commande peut altérer l'intégrité du système. Une requête est en lecture seule |
| Rejeu | Compliqué | Facile | Rafraîchir l'écran est sans risque. Relancer une commande en cours peut 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 les 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 une seconde de plus, l'utilisateur est prêt à 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.