Bounded Context Canvas

Auteurs : Kenny Baas, Kim Lindhard, Michael Plöd, Maxime Sanglan-Charlier
Source : The Bounded Context Canvas
Date : 21/05/2023

---

Traducteur : Fabrice Aimetti
Date : 30/06/2023

---

Traduction :

Le Bounded Context Canvas est un outil collaboratif permettant de concevoir et de documenter la conception d'un unique contexte délimité (bounded context).

Si vous ne savez pas ce qu'est un contexte délimité, vous pouvez vous reporter au manuel DDD Reference d'Eric Evans et à l'article de Martin Fowler.

Le canevas vous guide tout au long du processus de conception d'un contexte délimité en vous demandant de prendre en compte et de faire des choix sur les éléments clés de sa conception, du nommage aux responsabilités, en passant par son interface publique et ses dépendances.



Téléchargez le canevas vierge

Comment l'utiliser

Pour commencer rapidement avec le canevas de contexte délimité, complétez le canevas dans l'ordre où les rubriques sont présentées dans le chapitre Définition des rubriques.

Commencez par le nom et la description du canevas afin de clarifier sa raison d'être et ses principales responsabilités en une phrase ou deux. Vous pouvez ensuite remplir les autres rubriques du canevas dans n'importe quel ordre. Vous pouvez concevoir le canevas de l'extérieur vers l'intérieur en commençant par la communication entrante ou de l'intérieur vers l'extérieur en commençant par les règles métier et le langage du domaine.

Il se peut que vous ne disposiez pas de toutes les informations nécessaires pour compléter certaines rubriques du canevas. Dans ce cas, vous devrez utiliser d'autres techniques de modélisation pour trouver les informations dont vous avez besoin.

Formats alternatifs

Le format par défaut du canevas Bounded Context présenté ci-dessus n'est pas le seul disponible, vous en trouverez d'autres ci-dessous. N'hésitez pas à expérimenter de nouveaux formats.

Couloirs de nage des cas d'utilisation : ce style organise la rubrique "communication" en couloirs de nage montrant la séquence dans laquelle les interactions se produisent en utilisant le format suivant : message entrant -> décision(s) prise(s) -> message(s) sortant(s).

Définition des rubriques

Voici une brève explication de chaque rubrique du canevas.

Nom

Il est difficile de donner un nom. Le fait d'écrire le nom de votre contexte et d'obtenir l'accord de l'équipe orientera la manière dont vous concevrez le contexte.

Objectif

Quelques phrases décrivant le pourquoi et le quoi du contexte en langage métier. Aucun détail technique à ce stade.

La rédaction de l'objectif vous oblige à formuler clairement des idées imprécises et à veiller à ce que tous les membres de l'équipe soient sur la même longueur d'onde.

Décrivez l'objectif d'un point de vue métier, vous pouvez également nommer les acteurs clés pour lesquels le contexte délimité apporte de la valeur.

Classification stratégique

Quelle est l'importance de ce contexte pour le succès de votre organisation ?

• domaine principal : une initiative stratégique clé
• domaine support : nécessaire mais pas un facteur de différenciation
• domaine générique : une capacité commune que l'on retrouve dans de nombreux domaines

Quel rôle le contexte joue-t-il dans votre modèle d'entreprise ?

• générateur de revenus : les gens paient directement pour cela
• générateur d'engagement : les utilisateurs l'apprécient mais ne paient pas pour cela
• générateur de conformité : protège la notoriété et l'existence de l'entreprise.

L'évolution du concept (voir les Cartes de Wardley) :

• genèse : nouveau domaine inexploré
• sur mesure : les entreprises construisent leurs propres versions
• produit : des versions prêtes à l'emploi existent et offrent une certaine différenciation
• produit de base : il existe des versions hautement standardisées.

Pour une description détaillée de la genèse, du sur-mesure, du produit de base, voir les définitions dans les Évolutions des Cartes de Wardley.

Pour obtenir de l'aide pour remplir cette section du canevas, voir les Diagrammes des Domaines de base (Core Domain Charts).

Rôles du domaine

Comment pouvez-vous caractériser le comportement de ce contexte délimité ? Reçoit-il de gros volumes de données et les analyse-t-il pour en tirer des enseignements - un contexte d'analyse ? Ou applique-t-il un flux de travail - un contexte d'exécution ? L'identification des différents rôles joués par un contexte permet d'éviter le chevauchement des responsabilités.

Jetez un coup d'œil aux Archétypes de contextes délimités d'Alberto Brandolini et aux Stéréotypes de rôles d'objets de Rebecca Wirfs-Brock pour une analyse plus approfondie de cet espace. La feuille de travail Model Traits contient des exemples de rôles générés par la communauté (Model Traits était l'ancien nom des rôles de domaine).

Communication entrante

La communication entrante représente les collaborations initiées par d'autres collaborateurs.

Messages

Les messages sont les informations qu'un collaborateur envoie à un autre. Trois types de conversation peuvent avoir lieu entre des contextes délimités. Une demande pour faire quelque chose (une commande), une demande d'information (une requête), ou une notification que quelque chose s'est produit (un événement).

Le mot "message" est utilisé au sens général et n'est lié à aucune implémentation. Aucun bus de messages ou flux de travail asynchrone n'est obligatoire. Une commande, par exemple, peut simplement consister à afficher des données à partir d'un formulaire HTML sous la forme d'une commande HTTP POST.

Collaborateurs

Les collaborateurs sont d'autres systèmes ou sous-systèmes qui envoient des messages à ce contexte. Il peut s'agir d'autres contextes délimités, de frontaux (web ou mobile) ou d'autres choses.

Si le contexte délimité possède une interface utilisateur (par exemple, un micro-frontend), le type de collaborateur est l'interaction directe avec l'utilisateur.