Présentation du Bounded Context Canvas

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é), en architecture logicielle, est un sous-système aligné avec une partie du domaine métier.

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.

BCCanvasV3_FR

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
Diagramme de flux des messages – légende

Diagramme de flux des messages - Exemple
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 :

CoreDomainChart-FR
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.

Stuff - Interface du BC
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 !

The good enough software

A couple of days ago, I was having a coffee with one of my colleague and he told me that:

“Almost every time we’re asked to develop a new feature, we provide our project leader with 3 ways of doing it: the quick & dirty way, the way we’d do it if we’d have the time to and, finally, the one in the middle: the way that allows us to meet the deadline doing something acceptable. Most of the time the later is chosen.”

WUT

Even if he told me that he was not so happy with it, he also said that it’s how it is and that they did not have the choice if they wanted to meet the deadline :-(

This plague has a name: the good enough software.

Kevlin Henney has a nice definition for this, here it is:

The good enough in good enough software refers to intrinsic quality: defect management, code quality and performance are not prioritized or managed as critical qualities. Deadlines end up being the focus, starting with initial time to market. While such an approach can appear to pay benefits in the short term, such an approach makes little economic sense in the long run — accidental costs and delays arising from quality issues come to define the development rather than features. (from InfoQ)

As a developer you should not provide 3 different ways of doing things. You should not jeopardize your projects by lowering the level of quality you’d like to put into. It’s up to your project leader/manager to strive to reduce the number of functionalities instead, it’s part of their job and this is where negociation is encouraged! As a developer you should always focus on defect management, performance and craftsmanship the same way.

This is why worse is better.

Worse is better has been coined by Richard Gabriel and as stated on Wikipedia:

The idea is that quality does not necessarily increase with functionality. There is a point where less functionality (“worse”) is a preferable option (“better”) in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.

If you do care about this, and I know you do, but your management don’t, well, quit your job :-)

And while you’ll be doing job interviews, please ask people you’re gonna meet this simple question: Is code quality taken as a corporate asset? You’ll know if it’s worth applying for a job there!