Get best of the week

Conception d'un contexte délimité avec un canevas de contexte délimité: recette d'atelier

Parmi les sujets de la prochaine conférence TechLead Conf 2020 , une discussion détaillée sur la conception pilotée par domaine et EventStorming. En plus de préparer un rapport à 2 emplacements de Konstantin Gustov sur DDD , un rapport de Sergey Baranov sur EventStorming et un mitap au cours duquel nous allons créer un radar DDD, nous avons décidé de traduire un article sur l'une des méthodes les plus populaires pour concevoir un contexte délimité.

Comment diviser un grand système en composants plus petits et plus faciles à gérer? On me pose souvent cette question, j'ai donc rassemblé mes connaissances dans cet article.

Dans DDD, un grand système est décomposé en contextes limités (commentaire d'un traducteur: ci-après ils seront appelés contextes bornés) , qui deviennent des frontières naturelles - comme des microservices dans le code et en équipes dans une organisation.

Il n'y a aucun moyen d'identifier rapidement et facilement de bonnes limites pour un contexte délimité. Cela nécessite une connaissance approfondie et approfondie de l'entreprise et du domaine. Ce format d'atelier est conçu pour répondre à ces deux besoins et utilise deux outils pour trouver la conception de système la plus efficace: EventStorming et Bounded Context Canvas.

image

«J'ai développé cette toile dans le cadre de la conduite d'ateliers DDD lors d'événements publics et de sessions d'entreprise. N'hésitez pas à modifier sa structure si vous trouvez les formats qui vous conviennent le mieux. »

Recette


La recette principale se compose des éléments suivants:

  1. EventStorming (minimum 1 heure).
  2. Modélisation des candidats pour un contexte borné (minimum 30 minutes).
  3. Modélisation du flux des messages du domaine (au moins 30 minutes).
  4. Toile de contexte délimité (minimum 90 minutes).
  5. Création de cartes contextuelles (au moins 45 minutes).

Comme point de départ, je recommande d'allouer une journée entière à cet atelier. Cela vous aidera à comprendre combien de temps vous avez vraiment besoin pour mener correctement l'atelier. S'il est coûteux (en temps) de rassembler tout le monde, essayez d'allouer immédiatement deux jours pour que tout soit fait.

Idéalement, les participants devraient être des experts en la matière et des experts techniques. Si cela est difficile à organiser, essayez de vous assurer que les experts du domaine sont à l'atelier pendant au moins la première heure.

Principes de base de la modélisation


Pour mener une session avec des experts, vous avez besoin d'une salle spacieuse. Si vous choisissez un petit public, vous serez très probablement déçu des résultats. Chaque groupe de 4 personnes aura besoin d'au moins 4 mètres au mur.

Je décrirai ma méthodologie sous une forme libre, sans réglementation stricte. Cependant, gardez à l'esprit:
«Nous basculons constamment entre l'espace de problème et l'espace de solution. "Nous recherchons des informations, créons un modèle, recherchons des informations supplémentaires, mettons à jour le modèle, etc."
Et un autre point important: le but de la session est de développer des options et de développer la capacité d'offrir de meilleures options à l'avenir.

1. EventStorming


Pour concevoir un système, vous avez besoin de deux choses: une bonne idée générale de l'ensemble du système et une compréhension assez approfondie des détails de chaque domaine. Pour ce faire, commençons par EventStorming .

EventStorming est une méthode de conception collaborative qui vous permet de simuler une zone problématique importante du début à la fin, et vous permet également d'explorer un grand nombre de détails si nécessaire.

image

Si c'est la première fois que vous faites cela, je vous recommande de réserver 1 à 2 heures sur EventStorming. Après avoir terminé EventStorming, je recommande de se diviser en groupes de 4 personnes.
Lors de TechLead Conf 2020, Sergey Baranov parlera de l'expérience pratique avec EventStorming .

2. Recherche de candidats pour un contexte délimité


Une fois votre domaine modelé de manière large et approfondie sur EventStorming, vous pouvez commencer à regrouper et fusionner des fragments dans un contexte borné.

image

Il existe de nombreuses méthodes pour déterminer le contexte borné. Je recommande de commencer par ce qui suit:

  • Commencez par la valeur - identifiez les parties principales du domaine qui sont les plus précieuses pour l'entreprise.
  • Commencez par un modèle simple - créez un modèle naïf en divisant la chronologie en étapes successives.
  • Recherchez les événements clés - les événements commerciaux qui affectent différentes parties du processus commercial.

Pour la première fois, ne passez pas plus de 30 minutes sur cette tâche. Invitez le groupe à créer le modèle de contexte borné d'origine comme point de départ. Il n'est pas nécessaire qu'elle soit parfaite et il est peu probable qu'elle soit la solution finale.

La sortie doit être dans une liste de noms de contexte délimités sur un tableau à feuilles ou un papier. Vous ne pouvez pas modifier physiquement EventStorming si vous avez plusieurs groupes.

Prochaines étapes


Vous pouvez immédiatement voir plusieurs façons de modéliser le système. Pour l'instant, choisissez-en un pour le travail et notez les autres modèles possibles (ils vous seront utiles plus tard). Vous pouvez également comprendre qu'il vous manque des informations sur le domaine. Si tel est le cas, effectuez un autre cycle de EventStorming.

3. Modélisation du flux de messages du domaine


Une façon de valider votre conception et de rechercher des points d'amélioration consiste à visualiser l'interaction des contextes délimités dans des scénarios de système métier complets.

Si le flux de domaine s'est révélé complexe, avec un grand nombre de dépendances et de connexions bidirectionnelles, votre conception est fragile et nécessite une analyse plus approfondie.

De nombreuses méthodes de visualisation peuvent être utilisées pour modéliser les flux et les cas d'utilisation, notamment les diagrammes de séquence UML et les diagrammes de cas d'utilisation UML. Je recommande d'utiliser l'option de narration de domaine .

Lors de la modélisation du flux de messages d'un domaine, les contextes délimités sont les acteurs de l'histoire. Ainsi, une histoire typique commence avec l'utilisateur essayant d'atteindre un certain objectif, et l'interaction entre les contextes bornés vise à fournir à l'utilisateur une solution.

image
Un exemple fictif d'un flux de messages de domaine La

modélisation des flux de domaines stratégiques vous permet d'obtenir des commentaires sur les contextes délimités proposés. Il montre comment les contextes collaborent entre eux et dépendent les uns des autres pour mener à bien un processus métier complet. Cela peut aider à trouver une conception alternative.

La question que vous devez vous poser est de savoir si la description de chaque contexte délimité correspond au rôle qu'il joue dans le flux de domaine. Sinon, il est probable que le nom ou les limites du contexte nécessitent une refonte.

Prochaines étapes


Étant donné que vos flux de domaine déterminent la relation entre les contextes limités, vous pouvez immédiatement détecter les défauts de conception évidents. Vous pouvez revenir à l'action précédente et mettre à jour les candidats pour un contexte limité ou effectuer une deuxième itération de EventStorming. Vous pouvez également écrire vos réflexions sur la conception et collecter plus d'informations sur les prochaines étapes avant de commencer la refonte.

4. Toile de contextes délimités


La prochaine étape de la conception est le développement de candidats pour un contexte délimité, en utilisant les détails des critères de conception clés. Votre équipe doit choisir le contexte délimité que vous considérez le plus important. Limitez la discussion à un maximum de 3 minutes. Il n'est pas essentiel d'être précis à 100%.

Maintenant, dessinez un canevas de contexte délimité et suivez ces étapes pour remplir les détails. Je recommande d'utiliser 1 feuille de paperboard ou papier de même taille.
Après avoir terminé ces étapes, répétez le processus jusqu'à ce que vous ayez identifié tous vos contextes délimités. Essayez de partager votre temps également entre les candidats identifiés pour un contexte délimité.

4.1 Définition du contexte général


Commencez par définir le nom de votre contexte délimité et sa description. La description doit montrer l'objectif du contexte dans le domaine et son rôle dans l'entreprise, et non les détails de la mise en œuvre.

Ensuite, vous devez faire une classification stratégique. Le contexte borné est-il la partie principale du système, un élément auxiliaire, un élément commun ou autre chose? Lisez l'article de Vlad si vous avez besoin d'aide pour choisir.

image
Par exemple, un canevas de contexte délimité rempli après la première étape.

Prochaines étapes


Si vous ne pouvez pas trouver un nom clair, ou écrire une description cohérente et précise, ou si vos termes pour le langage ubiquitaire (UL) sont ambigus, considérez cela comme une rétroaction à votre conception. Envisagez de repenser les bordures ou prenez une note et revenez plus tard (il est généralement préférable de revenir plus tard).

4.2 Clarification des règles commerciales et formation d'un langage commun


Revenez maintenant à EventStorming et regardez les notes de ce contexte délimité. Trouvez les règles et politiques commerciales les plus importantes, puis essayez de sélectionner les 3 plus importantes et ajoutez-les au canevas.
Konstantin Gustov à TechLead Conf 2020 parlera de ses nombreuses années d'expérience avec Ubiquitous Language et d'autres composants DDD à Raiffeisen.
C'est également le bon moment pour rechercher des mots ou des phrases clés pour les ajouter au canevas dans la section Langage omniprésent. Vous continuerez à ajouter des mots et des phrases tout au long de l'atelier, maintenant ce n'est que le point de départ.

image

4.3 Analyse des fonctionnalités


L'étape suivante consiste à explorer les possibilités offertes par le contexte borné. Cela clarifie non seulement ce qu'il fait, mais donne également beaucoup de commentaires pour la conception. Vous pouvez poser des questions telles que:

  • Ce contexte est-il surchargé de responsabilités?
  • Les opportunités semblent-elles liées?
  • Les capacités correspondent-elles au nom et à la description du contexte?
  • Et si nous sortions cette opportunité de son contexte?

Commencez à définir des opportunités en introduisant une interface publique. Que peuvent demander les consommateurs à ce contexte délimité et quelles commandes peuvent-ils invoquer? Utilisez des flux de données de domaine pour voir ce dont les consommateurs ont besoin dans ce contexte délimité.

Toutes les fonctionnalités ne sont pas activées par des commandes et des demandes provenant de l'extérieur. Certaines fonctionnalités peuvent être lancées de l'intérieur. Par exemple, des tâches planifiées. Parfois, vous pouvez remarquer que les opportunités sont regroupées, par exemple, une commande, une demande et une notification. Si c'est le cas, assemblez-les sur la toile et donnez un nom au cluster.

Vous pouvez avoir le sentiment que la responsabilité est inappropriée et doit se rapporter à un autre contexte délimité. Si oui, sélectionnez-le avec une sorte de marque d'identification sur l'autocollant.

image

Prochaines étapes


Si vous trouvez difficile de déterminer les capacités de contexte ou si vous pensez que certaines d'entre elles sont manquantes, je recommande de revenir à EventStorming et de modéliser ce contexte délimité plus en détail en mettant l'accent sur la recherche des capacités nécessaires pour d'autres contextes ou services.

Approfondissement des capacités [facultatif]


Présentez chaque opportunité sur votre toile pour des fonctionnalités supplémentaires. Ce détail supplémentaire vous aidera à trouver des modèles alternatifs. S'il n'y a pas assez d'espace sur la toile pour les pièces, trouvez une autre feuille de papier ou de l'espace sur le mur. Vous pouvez approfondir autant de couches que vous le souhaitez.

4.4 Dépendances


Les dépendances sont nécessaires si nous voulons la modularité, mais elles provoquent également un large éventail de problèmes commerciaux, techniques et sociaux. Par conséquent, il est important de voir les dépendances, de comprendre leur influence et d'envisager des options alternatives. La dernière étape de la conception d'un contexte borné consiste donc à s'assurer que vous capturez toutes les dépendances clés de votre contexte borné.

En parcourant le résultat EventStorming et les diagrammes de flux de domaine, identifiez chaque dépendance qui a un contexte limité et notez les informations suivantes:

  • le nom d'un autre contexte ou service borné;
  • Une brève explication de la raison pour laquelle la dépendance existe
  • où est la dépendance: à l'intérieur de ce système ou dans un système externe (par exemple, un service tiers);
  • type de relation: il s'agit d'une dépendance entrante (un autre service dépend de ce contexte borné), sortante (ce contexte borné dépend d'un autre), interface bidirectionnelle ou utilisateur (la dépendance est un certain type d'interface utilisateur).

Questionnez chacune des dépendances: si elle est nécessaire, quels sont les coûts et les avantages de sa disponibilité. S'il semble que vous pouvez vous en passer, marquez la dépendance avec un autocollant jaune.

image

4.5 Critique constructive


Lorsque vous avez terminé de remplir le canevas, prenez quelques minutes pour évaluer de manière critique la conception résultante de votre contexte délimité. Répartissez vos avis dans les catégories suivantes:

  • Bon : les aspects de conception que vous aimez.
  • Mauvais : aspects de conception que vous n'aimez pas.
  • Incertain : aspects de conception dont vous n'êtes pas sûr.

4.6. Réflexion et répétition


Un bon design est itératif. Avant de passer au contexte délimité suivant, reculez et regardez la vue d'ensemble. Avez-vous appris quelque chose qui est contraire à votre conception? Si tel est le cas, biffez les limites proposées, puis continuez à concevoir le prochain contexte délimité.

À ce stade, demandez-vous si le domaine est modélisé de manière suffisamment détaillée. A-t-il été difficile de remplir certaines parties de la toile? Si tel est le cas, essayez une autre série d'EventStorming dans le domaine ou dans certaines parties de celui-ci.

5. Création de cartes de contexte


Après avoir créé un canevas pour chaque contexte délimité et collecté les commentaires de conception, la prochaine partie de la session est un retour à l'exploration. Cette fois, vous disposez d'un ensemble complet de connaissances qui vous aideront à trouver les meilleures options de conception.

Le résultat de cet exercice est une collection de cartes de contexte de base - visualisations des relations structurelles entre les contextes délimités et tous les autres diagrammes que vous jugez nécessaires, tels que les diagrammes des flux de domaine. Chaque équipe doit développer au moins 3 cartes de contexte, chacune d'elles montrant les options possibles pour construire le système.

image
Un exemple de carte contextuelle très précise, pour cet atelier c'est suffisant.

Nous tiendrons une réunion à TechLead Conf 2020, où nous analyserons les différentes techniques, modèles et anti-modèles de DDD et collecterons un radar visuel. Qui sera publié après la conférence.
L'activité finale peut être réalisée sous forme libre. L'objectif est d'examiner les informations collectées et de les utiliser pour développer un certain nombre de conceptions de systèmes. Comme point de départ, je recommande:

  • Affichez tous les avis collectés pour chaque contexte et testez les avis «mauvais» et «non sécurisés».
  • Posez des questions «et si» ...
  • "Et si nous transférions cette opportunité dans un autre contexte délimité?"
  • "Et si nous saisissons cette opportunité et déplaçons l'une des sous-fonctions dans un autre contexte délimité?"
  • "Et si nous divisons le contexte délimité en plusieurs contextes?"
  • "Et si nous saisissons une opportunité dans chacun de ces trois contextes et que nous l'utilisons dans un nouveau contexte?"
  • "Et si nous dupliquons des fonctionnalités pour éliminer la dépendance?"
  • "Et si nous créons un service commun pour réduire la duplication dans différents contextes?"
  • "Et si nous isolions les opportunités vraiment clés et déplacions le reste dans un endroit plus paisible, dans un contexte séparé?"

Si vous préférez visualiser ces transformations, les illustrations suivantes peuvent être utiles:

image

image

image

Clôture de l'atelier


Pour terminer la session, chaque groupe doit présenter une sélection des cartes contextuelles qu'il a créées et discuter des compromis de chaque conception. Vous devez expliquer votre choix, car pour cela, une présentation de 5 à 10 minutes suffit généralement.

Ce que vous devez considérer dans la présentation:

  • : .
  • : .
  • , , .

- TechLead Conf 8 9 . 32 , , , , DDD .

- — ( , ). , .

More articles:


All Articles