Un Bounded Context "utilisateur" ?

Quelle drôle d'idée : on m'a toujours dit que "User", c'était tout sauf un Bounded Context, la fausse bonne idée, le truc à pas faire. Alors quoi ?

Partons du problème : la modularisation, c'est bien, mais comme le soulignent Mathias Verraes et Rebecca Wirfs-Brock, c'est une démarche qui relève de l'espace des solutions. Autrement dit, vos utilisateurs n'en ont rien à faire. Pas plus que de vos user stories, si vous y réfléchissez bien. Pour eux, la seule chose qui compte, c'est une application utile et facile à utiliser.

Cela suppose que l'utilisateur dispose d'une interface unique lui permettant de tout faire et de passer de manière transparente d'un contexte à l'autre. Si j'achète un produit et que je souhaite la facture correspondante, il serait aberrant que je doive me connecter à une application dédiée à la facturation : le flux de travail serait rompu. Pourtant, en termes d'API, il est certain qu'il y aura une API dédiée à la facturation.

Cela dit bien la nécessité d'un contexte destiné à présenter l'information à chaque profil utilisateur, à chaque persona. Il présente de l'information issue de tous les autres contextes et possède son propre langage. Par exemple, le langage d'un front-office sera généralement un langage simplifié, intelligible au plus grand nombre, tandis que celui du back-office restera un langage spécialisé, parlé par les experts du métier.

On imagine assez bien ce que ça donnerait dans un service que nous connaissons tous, Doctolib : on voit d'ici le contexte "Professionnel de santé", le contexte "Patient" et le contexte "Administrateur".

Dans le cas d'une Single Page Application (SPA), appeler plusieurs APIs depuis le front n'est pas idéal. Ainsi, on lui adjoint généralement une API dédiée, et cela s'appelle un BFF : Best Friend Forever Backend For Frontend. Comme souvent, tout est dans le titre, mais voyons tout de même ce que cela signifie :

• Un BFF offre à la SPA un point d'entrée unique pour des requêtes orientées écrans. Exemple : donne-moi l'historique de mes commandes avec pour chaque commande un lien vers la facture correspondante. Des informations en provenance de 2 contextes, compilées en 1 seule réponse.

• Un BFF permet de mutualiser l'authentification ; en OAuth2, par exemple, vous devrez vérifier la validité du token auprès du fournisseur d'identité, mais aussi garder l'information des jetons invalidés par la déconnexion volontaire de l'utilisateur. Tout cela nécessite un peu de code, autant ne le faire qu'une fois.

Un BFF est donc essentiellement un proxy : il facilite l'interaction en lecture et en écriture avec les autres contextes, qui ignorent tout de l'utilisateur (en particulier, ils ne connaissent que les rôles). L'ensemble SPA + BFF constitue le contexte utilisateur, et il y en a autant que de persona.

Les micro front-end pourraient aussi avoir un coup à jouer dans ce cas d'usage, mais ce sera pour une autre fois 😊