En tant que voyageur, quand je paie ma course en ligne, j’aimerais recevoir ma facture ensuite.
Les user stories exposent par nature un biais événementiel. En se focalisant sur une histoire individuelle elles suggèrent au développeur de suivre le même flux lors de l’implémentation.
A grand coup de design pattern peut-être on va mettre en place un DrivePaymentListener qui va "écouter" l’occurence d’un paiement et "triggerer" l’émission d’une facture.
Une alternative, suggérée par l’analyse des besoins, consiste à extraire les requis avant de foncer sur l’implémentation.
Donc réfléchir surtout aux états, plus qu’aux événements :
Toutes les courses payées en ligne doivent être facturées
Cela permet :
1️⃣ de challenger un minimum : seulement les courses payées en ligne ? toutes ? facturées tout de suite, 1h après, en fin de journée ?
2️⃣ de découpler vraiment : en fait la facturation n’est pas liée au paiement en ligne.
3️⃣ donc de réutiliser : quand les courses seront payées autrement il n'y aura pas de rework
4️⃣ d’être robuste : pas de facture oubliée parce qu’on a perdu l'événement, pas de double facture parce qu’on a reçu l’événement deux fois. Les états rendent les traitements idempotent plus facilement que les événements.
5️⃣ d’être efficace : ha tiens, on peut sans doute traiter certaines choses en bloc plutôt que sur une base individuelle.
Il y a un risque ici de faire crier quelques agilistes : vade retro upfront design toussa.
Dans la réalité il a toujours mieux valu prendre une heure de réflexion avant de foncer dans le code. C’est juste pas très à la mode, c’est plus gai de faire du rework 10x.
#SoftwareEngineering #Agile