L'appel du client

"Bon, cela fait déjà 1 journée entière que tu travailles sur le projet. Quand pourras-tu montrer quelque chose ?"

Alors évidemment ça refroidit.

1 journée de dev, ce n'est pas énorme. Mais pour ceux qui attendent la mise en ligne pour atténuer leur inquiétudes, ça compte.

Alors évidemment, il ne faut pas compter montrer nos 3 tests qui passent au vert. Et encore moins de discuter de l'injection de dépendances.

le front-end

Mais que faut-il montrer ?

Vous avez codé 2 commandes :

l'authentification login
la réservation book

Le commande book est le coeur de l'application. Notre frontend pourrait présenter une liste de logement de vacances, et permettre de réserver l'un d'entre eux.

Imaginons le parcours utilisateur de réservation. Mettons-nous à sa place.

Le parcours le plus intuitif serait de :

se connecter à la plateforme avec son login / mot de passe
disposer d'un bandeau comportant une date de début / fin de réservation
voir tous les logements dont la location est disponible à cette date
choisir un logement et le réserver en 1 clic

Mais pourquoi commencer par une connexion ?

L'expert métier vous confirme qu'il faut l'identité du vacancier qui réalise la réservation. Il n'est pas envisagé de faire des réservations anonymes, qui préserve l'anonymat du vacancier. Parce qu'on souhaite apporter au loueur de la confiance sur le profil des vacanciers qui louent son logement.

L'identité

Ouvrons ici une parenthèse.

Et remarquez au passage comme cette question de l'authentification mérite un débat.

Son absence pourrait même être un avantage différenciant : "La seule plateforme de réservation de logement de vacances garantissant votre anonymat".

OK. Ce genre de service pourrait peut-être dégénérer vers des usages pas très enviables.

Mais si l'expert métier vous avait dit : "Personne n'a envie de créer de compte pour utiliser un service? Peut-on rendre cela facultatif ?".

Aïe. Revisitons notre premier test :

const app = new App(testDependencies())
await app.run([
    login({email:"faketenant@mail.com", password:"secret"}),
    book({
        accomodationId:"accomodation-1", 
        adults:2, children:3, 
        from : new Date("2024-06-02"),
        to :   new Date("2024-06-04"),
    })
]);
 
// Le calendrier comporte la réservation
const bookings = await app.dependencies.bookings.listBookingsForAccomodationId("accomodation-1")
expect(bookings).toHaveLength(1)

Nous avons imprudemment ajouté une règle métier, imposant une étape d'authentification par login et mot de passe avant de pouvoir faire une réservation :

login({email:"faketenant@mail.com", password:"secret"})

Pourquoi avoir fait cela ?

Par habitude. Car nous sommes habitués à disposer d'un login et d'un mot de passe pour utiliser une plateforme.

Un scénario sans création de compte

Dans une optique plus RGPD-friendly, on pouvait imaginer un parcours utilisateur différent.

Par exemple :

disposer d'un bandeau comportant une date de début / fin de réservation
voir tous les logements dont la location est disponible à cette date
choisir un logement
ouvrir un formulaire demandant l'adresse email et le paiement de la location
envoyer par e-mail un numéro unique permettant au vacancier de gérer sa réservation (annulation, décalage, etc...).

Dans ce scénario, plus de création de compte. Le paiement réussi qui valide la réservation.

Nous avons commis une belle imprudence dès l'écriture de notre premier test, en oubliant d'interroger l'expert métier sur ce sujet !

A quoi aurait ressemblé le test avec ce scénario ?

const app = new App(testDependencies())
 
await app.run([
    // Pas d'authentification préalable : cette commande book() est "publique"
    book({
        accomodationId:"accomodation-1", 
        adults:2, children:3, 
        from : new Date("2024-06-02"),
        to :   new Date("2024-06-04"),
    }),
]);
 
// Le calendrier comporte la réservation provisoire, en attente de paiement
const bookings = await app.dependencies.bookings.listBookingsForAccomodationId("accomodation-1")
expect(bookings).toHaveLength(1)
expect(bookings[0].status).toBe(bookingStatus.pending);

C'était beaucoup plus simple !

Enfin, plus simple dans un premier temps. Puisqu'il fallait ensuite gérer le paiement pour valider la réservation.

Le paiement

Le paiement ? Voilà un point dont nous n'avons pas discuté.

Retournons voir l'expert métier :

"Il n'y a pas de paiement pour la première version de notre plateforme. On ne fait que de la mise en relation entre un vacancier (préalablement inscrit) et un loueur. Nous entrons le catalogue des biens en location à la main, après avoir signé un contrat avec chaque loueur. Pour chaque vacancier qui réalise une réservation, il nous reverse une commission en tant qu'apporteur d'affaire."

Voilà qui nous sert de leçon.

Le développeur doit parfaitement connaître le business pour lequel il travaille.

18 Ameliorer Reservation 20 Requetes