La commande de réservation

Rappelons-nous le typage de notre commande book() défini au chapitre précédent :

function book(payload) {
    const {accomodationId,adults,children,from,to} = payload;
    return function (dependencies, context) {
        // Book accomodationId for the family from <from> to <to> 
 
        return context
    }
}

Mais avant de coder avec enthousiasme, revenons sur notre objectif : faire passer le test au vert.

Le strict nécessaire

Le piège : vouloir en faire plus.

Surtout pas. Ecrivons le strict nécessaire pour faire passer le test au vert. Pas une ligne de plus.

Quelle est la condition qui fait passer le test au vert ?

// Le calendrier comporte la réservation
const bookings = await app.dependencies.listBookingsForAccomodationId("accomodation-1")
expect(bookings).toHaveLength(1)

Il suffit que la réservation soit ajoutée au calendrier de l'hébergement.

le code de la commande

Le code minimal ne fait aucun contrôle. Il ajoute bêtement la réservation au calendrier sans aucun contrôle, donc sans aucune erreur.

La réservation comporte l'identifiant du vacancier locataire. Mais souvenons-nous que nous avons retiré ce paramètre pour des raisons de sécurité.

Comment le connaître ? En allant le chercher dans le contexte. Et si le contexte ne comporte pas d'utilisateur authentifié ?

Alors c'est une erreur qu'il nous faut gérer.

function book(payload) {
    const {accomodationId,adults,children,from,to} = payload;
    return function (dependencies, context) {
        const user = context.loggedUser; // Peut-être null !
        if (!user) {
            return context.withError(shouldBeLogged())
        }
        const booking = Booking.of({tenantId:user.id, accomodationId,adults,children,from,to});
        await dependencies.bookings.save(booking);
        return context
    }
}

Au passage, nous avons déclaré un moyen de construire une nouvelle réservation au travers d'une méthode statique Booking.of(). Et nos dépendances se sont aussi enrichies d'un objet bookings pour enregistrer la réservation dans l'état du système. Mais gardons cela pour plus tard.

Controverse

Alors là parfois un débat prend naissance.

"Mais ce n'est pas à la commande de vérifier si l'utilisateur est connecté".

"Il faut faire ça ailleurs. Dans un middleware. Non, dans le contrôleur."

Alors voici un argument qui permet de trancher : Seule la commande sait ce qu'il est possible de faire en fonction de l'utilisateur et de ses droits.

La commande porte la responsabilité d'autoriser ou non une réservation anonyme.

Donc c'est elle qui lève l'erreur "L'utilisateur doit être connecté pour faire une réservation".