Le Bounded Context Canvas est un outil collaboratif créé par Nick Tune. Il aide à concevoir et documenter un Bounded Context.
Un Bounded Context (contexte borné), constitue une frontière autour d’un modèle et de son langage métier. À l’intérieur de cette limite, la signification des termes métiers utilisés est sans ambiguïté, bien définie et comprise par toutes les parties prenantes. Le modèle est clair et les règles sont cohérentes.
Le canvas vous guide à travers le processus de conception d’un Bounded Context en vous demandant de faire des choix sur les éléments clés de design : de son nommage et ses responsabilités à ses interfaces publiques et ses dépendances.
Vous pouvez retrouver l’article original de Nick, en anglais, sur son blog → ici.
The Bounded Context Canvas V3
Comment ça marche ?
Il n’existe pas de recette miracle pour découvrir les différents contextes bornés, mais une connaissance fine du domaine vous y aidera certainement ! La phase de découverte et d’exploration d’un domaine constitue la partie cruciale du Domain Driven Design. Sans une vision partagée par toute l’équipe, aucune chance d’aboutir au produit demandé.
Pour ce faire, il existe plusieurs outils collaboratifs qui vont vous permettre de découvrir le domaine visuellement et collaborativement :
Event Storming
Ma préférence va à l’Event Storming qui est, comme son créateur Alberto Brandolini le décrit : “un acte délibéré d’apprentissage collectif”. Le but de cet article n’est pas de vous expliquer comment dérouler un atelier Event Storming, si vous n’êtes pas familiers avec la pratique, je vous encourage à regarder cette vidéo ainsi que de lire le livre d’Alberto.
Commencez par modéliser le cas nominal en répartissant les événements métiers importants sur la ligne du temps. Essayez ensuite d’identifier les événements qui apportent de la valeur, ils vous aideront à coup sûr à découvrir vos contextes “cœur de métier”.
Heuristique
Cherchez les événements clés/pivots, ce sont des événements du domaine qui indiquent généralement des changements d’état entre les différentes parties du processus métier. Ce sont souvent des marqueurs de début et/ou de fin d’un contexte borné.
À la fin de cette session d’Event Storming en mode “big picture” vous devriez être en mesure de commencer à noter sur des post-it des noms de contexte borné candidats.
Domain Message Flow Modelling
Choisissez un des contextes bornés candidats que vous avez trouvé lors de l’Event Storming, identifiez une liste de scénarios clés de ce contexte et réalisez un diagramme de flux des messages pour chaque scénario (plus d’info → ici).
Ce diagramme aide à visualiser tous les messages (commandes, événements et requêtes) qui circulent entre les différents acteurs, contextes bornés et systèmes externes, pour un scénario donné.
La notation est volontairement très simple afin de s’assurer que tout le monde soit capable de participer à l’atelier sans avoir besoin de théorie :
Voici un exemple d’utilisation :
Diagramme de flux des messages – légende
Diagramme de flux des messages – exemple
Modéliser un diagramme de flux des messages vous permet d’avoir un feedback rapide sur la pertinence du choix de votre contexte borné. Vous visualiserez très vite la façon dont les contextes interagissent entre eux afin de satisfaire un scénario.
Heuristique
Si votre diagramme semble trop complexe avec beaucoup de dépendances et de relations bidirectionnelles, il se peut que vos choix de contextes bornés soient erronés. Voyez-là une bonne opportunité de retravailler votre design avant de vous lancer dans le code ;)
Il n’est pas nécessaire d’identifier tout de suite les données véhiculées dans chaque message, cela peut très bien être réalisé dans un second temps.
Le Bounded Context Canvas
Il est temps maintenant de s’atteler à remplir le canvas.
Chaque contexte borné candidat possède son propre canvas, vous pouvez d’ailleurs commencer par remplir le canvas du contexte borné qui vous semble le plus important dans votre domaine.
Voici la liste des différentes sections et pour chacune, des indications sur comment les remplir.
Nom
Le nom du contexte borné. Référez-vous au résultat de vos ateliers Event Storming et Domain Message Flow Modelling pour la liste des contextes bornés candidats.
Heuristique
Posez-vous la question de la pertinence d’un nom de contexte qui contiendrait “Management/Gestion”. Bien souvent ce terme est employé comme fourre-tout et regroupe probablement plus d’un contexte. Ex : dans le cadre d’un domaine de location de trottinettes électriques, évitez “Gestion de la flotte”, cela regroupe certainement des contextes comme “Répartition de la flotte” et “Prévision de la demande” qui sont des candidats à part entière.
Description
Cette section sert à décrire brièvement le contexte borné, ses intentions et ses responsabilités. Quel est son rôle dans le domaine ?
Classification Stratégique
La classification stratégique contient 3 axes par défaut (Domaine, Business Model et Évolution). Il n’est pas forcément nécessaire de remplir les 3, ils servent avant tout d’exemple. Vous pouvez également ajouter les vôtres si cela vous semble plus pertinent.
1 – Domaine
Dans cette sous-section, le but est d’identifier l’importance que joue le contexte dans la réussite de l’organisation. Un moyen simple et efficace est d’utiliser le tableau ci-dessous :
Core Domain Chart
Ce tableau vous aide à visualiser l’importance stratégique d’un contexte borné (abscisses) et son niveau de complexité (ordonnées).
Le cœur de métier est la raison pour laquelle vous développez votre application au lieu d’en acquérir une sur le marché, c’est évidemment la partie qui nécessite le plus d’attention. Les contextes de support sont des contextes nécessaires au domaines, liés au business, mais qui ne possèdent pas un avantage compétitif équivalent au cœur de métier. Les contextes génériques représentent des concepts qui ne sont pas uniques au domaine (on y retrouve des choses comme l’envoi d’e-mails, le paiement, …) Il est totalement possible d’imaginer utiliser des services existants au lieu de développer ses propres domaines génériques.
2 – Business Model
Ici, vous décrivez quel rôle joue le contexte borné dans le business model de votre organisation.
Prenons l’exemple du business model d’un moteur de recherche comme Google. On pourrait imaginer que plus les utilisateurs effectuent des recherches, plus cela génère des revenus. Quand on y réfléchit bien, ce n’est pas le contexte de recherche qui est générateur de revenus, mais le contexte des publicités. Le contexte de recherche sert à l’attractivité. On peut aussi très bien penser qu’un contexte qui gère les problématiques de GPDR ait le rôle de conformité dans le business model.
3 – Évolution
L’idée de cette sous-section est d’imaginer à quel niveau de maturité se trouve le contexte, à l’aide d’une Wardley Map. Sur l’axe de l’évolution, plus un contexte est répandu ou commun, moins il aura de valeur ajoutée.
La 1e étape sur une Wardley Map représente la genèse. C’est là que vous pourrez placer votre contexte s’il constitue quelque chose d’innovant. Ensuite arrive l’étape du sur mesure. A ce stade on quitte l’état de POC (Proof of Concept) mais les développements sont encore très customisés. Si votre contexte se place dans l’étape produit, c’est peut-être que vous êtes assez matures et êtes en mesure d’offrir des services à d’autres contextes ou à l’extérieur de votre organisation. Enfin, lorsque le contexte se trouve à l’étape marchandise, c’est qu’il devenu un contexte très commun auquel tout le monde peut avoir accès facilement.
Cette carte sert avant tout à visualiser la chaine de valeur. Elle vous permettra dans un second temps d’imaginer comment vos contextes risquent d’évoluer dans le temps et ainsi d’anticiper au mieux les efforts à porter sur tel ou tel contexte.
Décisions Métier
Ici, vous noterez les contraintes, décisions et règles métier du contexte : Quelles sont les décisions importantes que le contexte borné doit prendre et pourquoi ?
Vous pourrez distinguer les règles métier des invariants.
Invariant : Un Invariant est une règle forte qui ne doit jamais être rompue. Ex : Vous ne pouvez pas prendre 2 rendez-vous le même jour avec le même médecin sur une plateforme de prise de rendez-vous médical en ligne.
Règle : C’est une règle métier dont on ne connait pas forcément à l’avance la vitesse à laquelle elle va être appliquée et donc, qui est sujette à compensation. Ex : Une personne commande une pizza en ligne, la « cooking policy » s’applique. On regarde si la pizzeria est en capacité de prendre la commande et on l’accepte, sinon, on annule la commande.
Langage Ubiquitaire
Listez ici la terminologie clé du contexte ainsi qu’une définition de chaque terme.
Heuristique
Prêtez une attention particulière au langage et à la signification de chaque terme dans un contexte. Si vous luttez pour trouver une bonne définition à un terme particulier du contexte, c’est peut-être parce qu’il cache plus d’une signification. Dans ce cas, la découpe de votre contexte est certainement à revoir. Pensez au terme “livre” qui peut avoir de nombreuses définition en fonction du contexte dans lequel il est employé (imprimerie, édition, librairie, simple lecteur, …) comme en parle si bien Grégory Weinbach dans cette vidéo.
Caractéristiques du Modèle
Cette section est vraiment ouverte et vise à définir la nature des comportements internes du contexte et/ ou le type du modèle.
Le type de modèle est une notion très intéressante qui a été déjà présentée à de nombreuses reprises par Alberto Brandolini. En 2012, en 2016 et tout récemment lors de la conférence en ligne D-DDD-D dans son talk Extreme Context Mapping (partie “the three archetypes”). L’idée est de montrer que des modèles similaires peuvent avoir des comportements très différents. Alberto parle de modèles “draft“, “execution” et “metrics“. Les modèles de type “draft” et “execution” partagent une structure de données très proche mais leur comportement diffère. Sur un modèle “draft“, il y aura des validations de structure et la donnée sera consolidée de manière incrémentale. Prenons l’exemple d’un panier sur un site e-commerce. On y ajoute des articles au fur et à mesure, des vérifications de surface sont faites, mais ce n’est pas avec un panier que le site va gagner de l’argent. Le modèle “draft” passe à “execution” suite à un événement de transition (cherchez-les sur votre Event Storming !) Notre panier devient alors une commande, avec laquelle le site e-commerce pourra gagner de l’argent. Ce modèle deviendra alors pratiquement read-only. Un 3e type de modèle, le type “metrics“, avec une structure semblable, servira à des fins de reporting ou d’analyse.
Nick fournit également une liste de type de comportements applicables à un modèle, dont vous trouverez la version française → ici.
Messages Consommés et Produits
On trouvera dans cette section la description de l’interface publique du contexte. Que produit-il comme message et que consomme-t-il ?
Voici les types de messages :
Commandes :
Le contexte qui produit une commande, demande au contexte destinataire de faire quelque chose, de réaliser une action. Une commande peut échouer.
Événements :
Un événement important pour le domaine qui est arrivé dans un contexte et qui peut intéresser d’autres contextes.
Requêtes :
Un contexte demande des informations à un autre contexte.
Interface du contexte borné
De nouveau, n’hésitez pas à jeter un œil à votre Event Storming, vous trouverez de quoi alimenter cette section !
Dépendances et Relations
Ici on listera les contextes et les systèmes externes depuis lesquels les messages arrivent – les fournisseurs – et les contextes qui consomment les messages publiés – les consommateurs -.
La relation est un texte libre où vous pourrez décrire succinctement la raison pour laquelle une dépendance existe.
Référez-vous à votre diagramme de flux des messages afin de voir avec quels autres contextes et systèmes externes votre contexte interagit.
Et après ?
Une fois que vous aurez rempli votre 1e canvas, profitez-en pour prendre un peu de recul avant de remplir le suivant. Regardez si les décisions que vous avez prises lors de vos discussions, n’ont pas d’impact sur la liste des contextes candidats que vous aviez imaginé au départ. Refaites un tour sur votre Event Storming et rectifiez au besoin.
N’oubliez pas que la modélisation est une activité itérative, comme Eric Evans le dit lui-même “il faut trois mauvais designs avant d’avoir trouvé le bon !”
Le canvas a été créé pour vous guider dans la découverte, la conception et la documentation des contextes bornés de votre domaine. Vous n’êtes toutefois pas obligés de le suivre à la lettre. Libre à vous de le modifier et l’adapter en fonction de vos besoins.
Tout au long de cette activité, pensez à noter les heuristiques que chacun a utilisé pour trouver et affiner la liste des contextes bornés de votre domaine. Cette liste, que vous pourrez mettre à jour régulièrement, vous servira à chaque fois que vous repartirez en mode exploratoire à la découverte des contextes bornés d’un domaine.
Bonne modélisation ! :)
Consultant et formateur
Si vous recherchez un accompagnement pour votre équipe ou une formation, je suis à votre disposition pour plus d’information, n’hésitez pas à me contacter !
one.hundred.acorns 