Nick Tune - Defining Socio-Technical Boundaries with the Bounded Context Canvas (EN)

[00:00:15] Alors euh, faisons un compte à rebours.
[00:00:19] Cinq, quatre, trois, deux, un.
[00:00:29] Partager l'écran.
[00:00:34] Bon, je devrais maintenant avoir la permission de contrôler la machine de tout le monde. Donc je vais regarder toutes vos photos, choisir celles que j'aime le plus, et je vous corromprai plus tard.
[00:00:46] Alors, tout le monde peut voir mon tableau Miro ? Quelqu'un pourrait-il taper dans le chat si vous pouvez voir mon écran Miro ? Oui, vous pouvez le voir. Super. Bien, bienvenue à ma conférence ce soir. C'est ma quatrième participation à Flowcon, des circonstances légèrement différentes cette année, mais c'est toujours bon de
[00:01:08] rencontrer beaucoup de monde d'une certaine manière et discuter des mêmes sujets.
[00:01:16] Ce soir, je vais parler de la façon de définir les limites sociotechniques avec un outil appelé le Bounded Context Canvas.
[00:01:25] Et comme vous pouvez le voir, je vais faire cette présentation sur Miro. Vous pouvez suivre avec le lien Miro ici, ou vous pouvez suivre sur le tableau distant. L'une ou l'autre approche conviendra.
[00:01:44] Alors le premier point que je voulais faire est que l'architecture sociotechnique n'est peut-être pas un mot que vous avez entendu avant, peut-être est-ce un mot que vous avez entendu avant. Ce n'est pas un mot qui n'est pas encore vraiment entré dans le dictionnaire public en technologie.
[00:02:03] Alors vous vous dites peut-être, si ce n'est pas un mot commun, ce n'est probablement pas si utile. Mais en fait, l'architecture sociotechnique est utile. Et si nous examinons certaines des recherches qui ont été menées au cours des deux dernières années, nous pouvons voir pourquoi c'est utile, et je peux aussi expliquer ce que c'est. Donc Nicole Forsgren, Jez Humble et Gene Kim, ils font leurs sondages Dora DevOps depuis quelques années maintenant. Je pense que c'est entre cinq et sept, j'ai perdu le compte, probablement quatre.
[00:02:36] Et ils ont aussi sorti un livre il y a quelques années, et ils ont parlé, ils ont examiné comment différentes entreprises fonctionnent, ce qui sépare les performants des performants moyens et des faibles performants, etc. Et ils ont trouvé tous ces euh, tous ces résultats. Et étonnamment, ce qu'ils ont découvert, c'est qu'une architecture faiblement couplée et une structure organisationnelle correspondante étaient l'un des plus grands prédicteurs de la performance en livraison continue. Je sais que d'après mon expérience de la livraison continue, des conférences et des livres au fil des ans, l'architecture n'a pas vraiment été au premier plan ou au centre, la pièce maîtresse de la livraison continue. Mais voilà qu'ils disent dans ce livre que l'architecture est essentielle, l'un des plus grands prédicteurs de la capacité de votre organisation à performer avec la livraison continue. Ils ont également constaté que cette qualité d'une architecture faiblement couplée et d'une structure organisationnelle vous permet de développer votre organisation et d'adapter les performances de manière linéaire, de sorte que chaque fois que vous ajoutez une nouvelle personne, vous obtenez une quantité prévisible de productivité de leur part. Ce n'est pas comme les entreprises typiques où nous avons de si gros goulots d'étranglement où ajouter plus de personnes ralentit les choses.
[00:03:51] Ce qu'ils disent en fait ici, c'est que en ajoutant plus de personnes, vous continuez à être plus productif si vous définissez correctement les limites architecturales et si vos équipes sont organisées autour de ces limites architecturales.
[00:04:05] Donc ThoughtWorks, ils ont fait des études sur leurs projets, et j'ai vu ça, je pense, lors d'une conférence de James Lewis il y a quelques années, et ce qu'ils ont trouvé sur leurs projets, c'est que
[00:04:20] ce qu'ils appellent quand le travail quitte l'équipe, donc en fait, quand une équipe doit collaborer avec une autre équipe sur un travail, il faut un ordre de grandeur de temps en plus à ces équipes pour accomplir ce travail, comparé à une seule équipe travaillant sur ce travail seule. Maintenant, ce n'est pas une règle universelle, mais en examinant cette découverte, en examinant les découvertes d'accélération, nous pouvons voir que les signes suggèrent qu'en ayant une architecture faiblement couplée et
[00:04:50] des équipes alignées sur cette architecture faiblement couplée, nous pouvons être plus efficaces en tant qu'organisations.
[00:05:02] Maintenant, ce qui a tendance à se produire quand on parle d'architecture faiblement couplée, d'équipes autonomes, etc., on commence à parler de microservices et d'équipes de deux pizzas. Et cette idée que si nous faisons juste de petites choses, alors nous aurons un bon design, nous aurons les bonnes limites, les bonnes équipes, etc. Mais, vous savez, réfléchissons-y une seconde. Obtenir ces grands gains de productivité juste en réduisant la taille des choses, rien n'est aussi facile, et concevoir des systèmes complexes ne sera jamais aussi facile que de dire : « Rendons les choses plus petites ». Et comme je le dis ici, nous n'aurions même pas de travail si c'était si simple, alors soyons reconnaissants que les choses ne soient pas trop simples.
[00:05:53] Et pensons à quelques-uns des principes ou à l'un des principes clés ici, c'est la complexité. Nous devons équilibrer la complexité locale et globale. Donc, si nous réduisons les choses, chaque pièce individuelle a moins de pièces mobiles, moins de taille, moins de volume, il est plus simple de comprendre cette pièce isolément. Et c'est la complexité locale. Le problème est qu'en ayant plus de pièces, il y a plus d'interactions entre ces pièces, et la complexité globale du système est plus élevée, les interactions entre ces choses.
[00:06:31] Donc la taille nous aide à équilibrer la complexité locale et globale. Et ce n'est qu'un des compromis clés. Si nous rendons tout trop petit, nous allons tout droit vers la complexité locale. Donc le local contre le global est un compromis. Et cela a aussi des impacts. Alors pensez, pensez aux résultats d'accélération. Ils parlent d'architecture et de structure organisationnelle.
[00:06:59] Donc, et si nous pensons à ThoughtWorks, en ayant plus de pièces qui sont plus petites, nous avons plus d'opportunités pour que des éléments de travail quittent l'équipe. Il est plus probable que plusieurs équipes collaborent sur un élément de travail. Par conséquent, plus de travail prendra un ordre de grandeur de temps en plus pour être achevé.
[00:07:24] Ce diagramme ici visualise ce qui se passe quand les choses deviennent trop grandes. Si nous commençons à rendre les services trop grands, nous devons agrandir l'équipe, nous avons plus de chemins de communication dans l'équipe, et nous avons une complexité sociale accrue, la complexité entre les personnes impliquées dans l'équipe. Donc beaucoup de compromis ici concernant la taille. Et c'est rendre les choses trop petites, rendre les choses trop grandes a beaucoup de compromis et ce n'est pas si simple.
[00:07:55] Alors, comment trouvons-nous de bonnes limites sociotechniques ? Qu'est-ce qui pourrait nous aider ici ?
[00:08:11] J'ai donc élaboré ce petit diagramme et je veux essayer de visualiser certains des acteurs clés impliqués dans ce système et les relations entre eux. Nous avons donc des équipes de développement logiciel. Et ce que font les équipes, c'est qu'elles identifient les problèmes de mes utilisateurs, comment nous pouvons résoudre ces problèmes. Et les équipes construisent ensuite une architecture logicielle, un système logiciel, qui fournit les capacités pour satisfaire ces besoins utilisateurs. Comme Melissa Perri l'explique dans son livre « Escaping the Build Trap », il s'agit d'un échange de valeur. L'entreprise crée de la valeur et les utilisateurs, les entreprises ou les clients échangent leur valeur contre la valeur commerciale, contre la valeur client.
[00:09:00] Alors, que pouvons-nous dire de ces relations qui pourraient nous aider à comprendre comment concevoir et faire évoluer de bonnes limites sociotechniques ?
[00:09:15] Voici une que j'ai préparée plus tôt.
[00:09:20] Donc ce que nous savons, c'est que l'architecture des équipes de développement ou la structure de votre organisation va être alignée sur l'architecture logicielle ou vice versa. Et c'est ce qu'on appelle la loi de Conway.
[00:09:38] Ce que nous savons aussi, c'est que l'architecture logicielle est un modèle du domaine d'activité dans lequel nous travaillons. Et le marché fait en fait partie de ce domaine.
[00:09:52] Donc, ce que cela nous dit vraiment, c'est, nous devons comprendre le domaine afin de modéliser l'architecture logicielle de manière faiblement couplée, de manière optimale, et cela devient alors le modèle pour l'organisation de nos équipes. Commencez donc par le domaine, examinez une architecture logicielle et essayez ensuite d'adapter les équipes à cette architecture. En réalité, c'est un processus beaucoup plus itératif.
[00:10:25] Mais en gros, ce que je dis, c'est d'essayer de commencer par le domaine.
[00:10:31] C'est la première partie de cette présentation. La deuxième partie aborde un peu le concept d'architecture de domaine avant d'arriver au canevas.
[00:10:46] Donc l'un des premiers points que je veux souligner est que lorsque les gens parlent de passer à des équipes produits, des équipes autonomes, alignées sur des parties du domaine. C'est une bonne décision, mais ce n'est pas une solution. Choisir d'aligner votre logiciel avec votre domaine, il n'y a pas de correspondance biunivoque car il existe de nombreuses façons de modéliser votre domaine. Vous devez concevoir les limites, vous ne les découvrez pas. Vous ne recherchez pas des limites parfaites qui existent.
[00:11:17] Alors, laissez-moi vous donner un exemple.
[00:11:20] Alors imaginons que vous travaillez dans un domaine.
[00:11:25] Et votre domaine a ces concepts.
[00:11:29] Donc vous avez des formes et vous avez des couleurs.
[00:11:33] Comment organisez-vous ces concepts de domaine dans vos limites architecturales, dans vos microservices ou vos équipes de deux pizzas, etc. ?
[00:11:45] Il y a pas mal de façons de faire cela, il y a plus de trois façons de faire cela. Vous pouvez organiser les choses par forme, vous pouvez organiser les choses par couleur. Vous pouvez organiser les choses en combinaisons uniques ou en choses qui doivent être utilisées ensemble. Et c'est vraiment de cela qu'il s'agit aussi dans la modélisation de domaine. Il n'y a pas de solution unique parfaite, trouver les limites du domaine est un processus de conception, un processus de découverte et de conception en soi.
[00:12:14] Et donc, pour trouver les bonnes limites, il y a quelques caractéristiques ou heuristiques à prendre en compte. La première est : quel est votre modèle d'affaires ?
[00:12:26] Donc un outil que nous pouvons utiliser ici est le canevas de modèle économique. Par exemple, si nous regardons les formes et les couleurs, si notre modèle économique tire 90% de nos revenus des couleurs, alors nous voulons peut-être organiser les choses par couleur. Mais si notre modèle économique génère 90 % de nos revenus par la forme, nous organisons peut-être les choses par la forme. Donc ça dépend. La façon dont nous alignons nos limites de domaine dépend de ce que nous optimisons en tant qu'entreprise, quel est le modèle économique.
[00:12:55] Et si vous examinez les modèles économiques, vous verrez qu'il existe de nombreux types de modèles économiques, et cet article parle de 50 d'entre eux, des plateformes, des marchés multifaces, du modèle freemium, etc. Donc, pour avoir des équipes faiblement couplées et une architecture faiblement couplée, vous avez besoin des limites de domaine.
[00:13:14] Et les bonnes limites de domaine, vous devez les relier au modèle économique.
[00:13:25] De plus, même si vous comprenez le modèle économique, cela ne suffit pas à choisir les bonnes limites, cela ne vous aide pas à trouver les candidats car il s'agit aussi de couplage. Nous devons comprendre quelles choses changent ensemble. Et c'est là que la conception pilotée par le domaine parle du langage, en regardant les mots du domaine qui sont utilisés ensemble.
[00:13:53] Alors, laissez-moi vous donner un exemple rapide de cela.
[00:13:57] Donc le concept d'une tomate pourrait être classé de différentes manières selon votre contexte ou selon votre domaine. La définition botanique d'une tomate est un fruit, mais si vous cuisinez, alors c'est un légume car il est utilisé dans des plats salés comme un légume. Et même lorsqu'il existe une définition scientifique des choses, la façon dont votre domaine, la façon dont les gens pensent dans votre domaine, peut contredire la science. Il y a cette histoire célèbre aux États-Unis d'Amérique, la Cour suprême dans les années 1800, ils ont déclaré que les tomates étaient des légumes, même si scientifiquement ce sont des fruits, afin qu'ils puissent leur imposer plus de taxes parce que les gens importaient des tomates pour éviter de payer la taxe. Et c'est l'essence du design piloté par le domaine. Le design piloté par le domaine consiste à modéliser votre domaine, à découvrir le langage du domaine, à l'utiliser pour trouver ces limites et à rechercher vos domaines clés, qui sont votre modèle économique. pour savoir où se concentrer. Voilà donc une rapide introduction au contexte de l'utilité du canevas. Je vais maintenant vous parler du canevas lui-même. Je vérifie rapidement l'heure. Je suis plutôt bon.
[00:15:19] Donc en parlant des frontières, des frontières sociotechniques, euh, ce sont en fait des paris. Vous faites un pari. Nous avons donc notre domaine, nous avons de nombreuses façons différentes d'architecturer notre système autour du domaine, nous avons de nombreuses façons différentes d'organiser nos équipes. Comment faisons-nous un choix ? Donc nous faisons un choix basé sur notre modèle commercial, basé sur des choses qui changeront ensemble. Donc minimiser le couplage, minimiser la nécessité d'effectuer un changement sur deux services, sur deux équipes en même temps. Mais pour faire ça, on devine. On devine comment les choses vont changer avec le temps parce qu'on ne peut pas prédire l'avenir. Donc notre architecture et notre structure organisationnelle sont un pari. Nous pensons que ces limites conduiront à la moindre quantité de couplage au fil du temps et à la moindre quantité de travail quittant une équipe.
[00:16:19] Ainsi, le canevas de contexte borné, je considère cet outil comme un moyen de visualiser votre pari.
[00:16:27] Vous pouvez donc voir toutes les informations clés en un seul endroit.
[00:16:34] Et vous pouvez vous demander, ce pari a-t-il un sens ? Sont-ce les bonnes limites que nous voulons atteindre dans notre système ? Pensons-nous que ces choix, de manière cohérente, conduiront au couplage le plus lâche et à la plus grande autonomie des équipes, et évidemment au meilleur flux entre les équipes ?
[00:16:56] Voici donc le canevas, et j'ai souligné comment chaque section du canevas aborde des choses, les concepts que je viens de vous expliquer. Donc en haut à gauche du canevas, nous avons une description. Je n'ai pas vraiment parlé de cette partie, mais j'ai parlé des autres. Donc la description concerne vraiment le but. Qu'est-ce qu'un contexte borné est effectivement un microservice, vous pouvez le voir ainsi, un module dans votre monolithe. La description est donc effectivement : qu'est-ce que cette chose fait ? Quel est son but ? Quels avantages commerciaux apporte-t-elle ? Et cette description, ce but, vous aide à comprendre à quel point vous seriez motivé en tant qu'équipe si vous construisiez cela ? Est-ce que cela vous passionne ? Seriez-vous fier de construire cela ? Est-ce un défi intéressant ? Cela vous aide donc à voir les choses du point de vue de l'équipe.
[00:17:48] Euh, je fais référence au livre de Daniel Pink, Drive, ici. Il parle de l'objectif, de l'autonomie et de la maîtrise comme étant les principaux facteurs de motivation pour les gens à produire leur meilleur travail et à se sentir connectés à leur travail. Pour en revenir au canevas, nous avons ensuite la classification stratégique. Cette section examine le modèle d'affaires et la stratégie commerciale. Comment ce contexte borné individuel joue-t-il un rôle dans votre modèle d'affaires et votre stratégie commerciale ? Nous avons ensuite les rôles de domaine qui décrivent le type de comportements que ce contexte borné possède. Et cela se concentre sur la complexité locale, à quel point les concepts à l'intérieur de ce contexte borné sont-ils compliqués ? Quand nous passons à cette section ici sur la communication entrante, la communication sortante, nous examinons à nouveau la complexité globale. Quelle est la taille de l'interface de ce contexte ? Combien de messages consomme-t-il et publie-t-il ? Donc c'est la complexité globale, le nombre de collaborateurs avec lesquels il interagit. Ce sont des dépendances d'équipe. Ainsi, pour chaque service ou microservice ou autre contexte borné avec lequel ce contexte borné communique, c'est une dépendance pour l'équipe qui possède ce contexte borné. C'est donc la complexité d'équipe ici.
[00:19:09] Et puis au milieu, nous avons le langage ubique, qui est comme un glossaire métier. Nous pouvons capturer ici des concepts clés du langage de domaine. Et les décisions commerciales sont en quelque sorte vos règles commerciales. Alors, quelle est la complexité de ces règles commerciales ? C'est donc la complexité locale. Donc, comme vous pouvez le voir ici, avec ce canevas, nous essayons de capturer tous les concepts dont j'ai parlé précédemment, qui affectent nos limites. Et donc nous pouvons considérer ce canevas global comme un pari avec toutes les informations au même endroit. Voulons-nous faire ce pari ? Ce contexte borné nous donnera-t-il un couplage lâche et une autonomie d'équipe ? C'est une dépendance pour l'équipe qui possède ce contexte délimité, donc c'est la complexité d'équipe. Et puis au milieu, nous avons le langage omniprésent, qui est comme un glossaire métier. Nous pouvons capturer ici les concepts clés du langage du domaine et les décisions commerciales sont en quelque sorte vos règles commerciales. Alors, quelle est la complexité de ces règles commerciales ? C'est donc la complexité locale. Alors, comme vous pouvez le voir ici, avec ce canevas, nous essayons de capturer tous les concepts dont j'ai parlé précédemment. Ils affectent nos limites. Et donc nous pouvons considérer ce canevas global comme un pari avec toutes les informations en un seul endroit. Voulons-nous faire ce pari ? Ce contexte délimité nous apportera-t-il un couplage lâche et l'autonomie de l'équipe ?
[00:19:51] Donc, le canevas du contexte délimité est sous licence Creative Commons. Il est sur GitHub. C'est la quatrième version maintenant. Euh, je l'ai commencé l'année dernière, mais il a changé plusieurs fois maintenant. Nous recevons beaucoup de contributions et de questions sur GitHub, tout va bien. Si vous avez des idées pour l'améliorer, c'est bien aussi. Il existe également un modèle Miroverse gratuit que vous pouvez utiliser ici. Euh, si vous n'avez jamais utilisé Miro auparavant, vous pouvez vous inscrire avec un compte gratuit. Allez dans les modèles, tapez canevas de contexte délimité et vous pouvez simplement le glisser sur votre tableau. Oui, c'est tout à fait gratuit.
[00:20:23] Et ici, j'ai préparé un exemple très partiel pour vous.
[00:20:29] Voici quelques-unes des idées que vous pouvez tirer du canevas. Alors si je commence ici avec la description,
[00:20:36] on voit que les gens parlent du fait qu'il est construit en utilisant CQRS et l'approvisionnement événementiel. Un peu trop technique.
[00:20:44] La description n'explique pas vraiment ce que le nom n'explique pas. Donc on peut voir ici, on ne comprend probablement pas le but de ce contexte. Nous n'avons pas capturé le pitch d'ascenseur pour expliquer aux non-techniciens pourquoi nous construisons cela et c'est important. expliquer ce qu'est cette capacité et comment elle apporte de la valeur. Donc si on voit un panneau d'avertissement comme ça,
[00:21:08] nous ne sommes pas prêts à construire cela, nous ne sommes pas prêts à nous engager dans ce pari parce que nous ne comprenons pas suffisamment la valeur commerciale. Nous pouvons ensuite voir ici, dans la classification stratégique, que nous avons quelque chose qui est fondamental et qui est également générique.
[00:21:22] Je parlerai de ces concepts plus tard. Mais quand on voit ces choses ensemble, ça nous dit, hmm, on a deux concepts différents ici. L'un est essentiel à notre modèle commercial et l'autre est un petit élément générique qui ne l'est pas. Voulons-nous que ces choses soient couplées ensemble ? Voulons-nous que les éléments génériques ralentissent le domaine central ou que se passe-t-il si nous voulons sous-traiter les éléments génériques plus tard, nous ne pouvons pas maintenant, c'est couplé ici.
[00:21:50] Nous pouvons voir dans les rôles du domaine sur le côté droit ici, il a trois rôles différents et ces rôles ont des objectifs très différents. Donc encore une fois, on dirait que ça en fait trop, la complexité locale est trop élevée.
[00:22:04] Et puis nous pouvons regarder l'interface ici, nous pouvons voir que ce contexte publie cinq messages à cinq collaborateurs différents. Donc nous avons cinq collaborateurs différents ici et ils ont tous leurs propres exigences. C'est probablement cinq dépendances différentes sur différentes équipes, cela pourrait être trop à gérer. Et nous pouvons également regarder l'interface elle-même et simplement penser, est-ce un bon design ?
[00:22:32] Alors si je regarde ici la collaboration avec le site web public, nous avons obtenir ma taxe foncière, comparer ma taxe foncière, ajouter une carte de crédit.
[00:22:42] Ces concepts ne vont pas ensemble, ajouter des cartes de crédit et consulter vos impôts. Je suis sûr qu'il y a une blague là-dedans, ouais, je ne la trouve pas. Mais de toute façon, c'est comme, c'est une idée de base de la façon dont vous pouvez utiliser ce canevas. Et certains des problèmes que vous pouvez découvrir en abordant ces différents aspects de la complexité locale, de la complexité globale, de la complexité sociale, etc.
[00:23:10] Et si vous êtes intéressé par le canevas, il y a aussi cet outil sur GitHub. appelé contexture. où une entreprise appelée software park, ils construisent un outil où vous pouvez gérer le canevas du contexte délimité. dans un système, le stocker en tant que données et peut-être le connecter à votre base de code. et générer automatiquement le canevas à partir de votre base de code. C'est un produit assez nouveau, donc ce n'est pas ce n'est pas encore si avancé, mais cela vaut la peine d'être surveillé.
[00:23:40] Alors je veux vite m'éloigner du canevas pendant quelques minutes et je veux parler de la façon dont vous arrivez à une situation où vous avez les informations sur le canevas afin de pouvoir les examiner. et évaluer ce pari.
[00:23:52] Alors, au cours de l'été, certains d'entre nous, nous avons mis en place ce processus de modélisation. Donc si vous êtes nouveau dans la conception axée sur le domaine, vous ne savez pas par où commencer, vous ne savez pas comment concevoir votre architecture de domaine. Ce processus vous donne une première itération à travers le processus de conception. Ce n'est certainement pas un processus de modélisation en cascade. C'est très itératif. Vous n'êtes pas toujours obligé de faire les choses dans cet ordre, vous ne les faites pas qu'une seule fois. Donc, si vous ne savez pas par où commencer, suivez ces sept ou huit étapes. puis faites évoluer votre design à partir de là.
[00:24:28] Alors la première chose que nous pouvons faire, c'est le canevas de modèle économique dont nous avons parlé, l'utiliser pour capturer notre modèle économique. Nous pouvons ensuite faire de l'event storming. Alors rassemblez beaucoup de monde, modélisez nos domaines. à distance ou en personne, ajoutez des chronologies.
[00:24:47] Et une fois que nous avons notre domaine établi,
[00:24:51] nous pouvons commencer à décomposer ce domaine en contextes délimités possibles, en recherchant des limites possibles à l'aide d'heuristiques, etc.
[00:25:02] Certaines des heuristiques dont j'ai parlé plus tôt, donc la valeur commerciale, l'organisation par concepts de domaine, le langage, la réflexion sur la taille de l'équipe. Apporter des contraintes techniques là-bas. Donc si vous avez des systèmes hérités, cela aura un impact sur vos limites, nous pouvons ensuite commencer à examiner comment ces systèmes communiquent entre eux, en concevant des flux de messages entre eux.
[00:25:26] Et nous pouvons utiliser le concept de bain à remous d'Eric Evans, donc nous concevons notre architecture, nous explorons différents cas d'utilisation et nous faisons évoluer l'architecture.
[00:25:38] Nous pouvons alors commencer à cartographier nos différents contextes délimités comme étant centraux, de soutien et génériques. pour nous assurer que nous savons si chaque contexte est l'un de ceux-ci et qu'il n'essaie pas de faire trop de choses.
[00:25:52] Donc j'ai passé très vite sur cela, mais une fois que vous avez parcouru ce processus une ou deux fois, vous serez en mesure de commencer à remplir les informations de ces outils sur votre canevas.
[00:26:07] Et ensuite, nous pouvons commencer à construire le canevas.
[00:26:11] C'est donc la section principale de la discussion maintenant, comment vous pouvez construire le canevas et comment vous pouvez euh, obtenir de la valeur de chaque aspect.
[00:26:21] Donc la première partie du canevas est le nom. Les gens pourraient penser que le nom est juste un espace réservé générique, qui n'a aucune valeur. C'est souvent, c'est souvent l'une des parties les plus utiles du canevas. parce que nommer des choses est difficile.
[00:26:37] Et les gens essaient d'utiliser, nous essayons juste d'utiliser des noms faciles. Donc des mots génériques comme gestion. Mais des mots comme gestion sont mauvais parce que parce qu'ils ils ne clarifient pas ce qui est à l'intérieur et ce qui est à l'extérieur.
[00:26:59] Donc un nom générique attire un comportement générique, le mot gestion est très générique. Donc, en regardant cela, tout ce qui est lié à la taxe foncière commerciale pourrait appartenir ici car le mot gestion ne dit pas quel aspect de la taxe foncière commerciale nous traitons. Donc un nom plus spécifique ici serait le registre des taxes foncières des entreprises. C'est plus spécifique, c'est plus clair et ça facilite l'identification de ce qui n'appartient pas ici.
[00:27:30] Aussi, avec le nom, euh, l'un des mots déclencheurs est "et". Chaque fois que quelqu'un utilise le mot X et Y, c'est déjà un signe d'avertissement que nous avons deux choses ici. Chaque fois que nous voyons le mot "et", nous pouvons toujours nous demander, et si nous séparions ces deux choses en contextes distincts ?
[00:27:51] Nous arrivons ensuite à la description.
[00:27:56] Et c'est là que les gens commencent à réaliser qu'ils avaient des idées différentes sur ce qu'était ce contexte. Donc, même lorsque les gens peuvent s'accorder sur le nom, lorsque vous les forcez à mettre ces pensées floues dans leur tête sur le canevas sous forme de quelques phrases ou de quelques paragraphes, c'est là que les gens ont des conflits d'idées. Comme, oh, je ne pensais pas que ça irait ici, je pensais que c'était ailleurs et ainsi de suite. Et donc, en écrivant simplement le nom et une description de votre contexte, vous pouvez déjà trouver où vous êtes en désaccord ou où vous avez eu un désalignement sur ces idées. Et aussi ici, nous pouvons aussi chercher le mot "et" ici aussi. Chaque fois que nous voyons le mot "et", chaque fois que nous joignons deux concepts, c'est toujours une limite potentielle pour séparer ces choses.
[00:28:48] Alors j'aime utiliser le format de quoi et pourquoi. Qu'est-ce que cette chose fait et pourquoi le fait-elle ? Et je dis toujours aux gens, imaginez que vous êtes dans l'ascenseur et que le PDG entre ou quelqu'un qui ne travaille pas dans le logiciel. Et vous devez leur expliquer sur quoi vous travaillez, quelle valeur cela apporte à l'entreprise et comment ça fonctionne ? Je pense que c'est une bonne façon de présenter cela.
[00:29:15] Et certainement, vous ne voulez pas vraiment mettre les détails d'implémentation ici. Nous parlons d'un argumentaire éclair, de l'objectif commercial. Nous ne parlons pas de la base de données ou du langage de programmation qui seront utilisés pour le construire. Nous ne sommes pas, nous ne sommes pas à ce niveau de détail ici.
[00:29:33] Nous examinons ensuite la classification stratégique. Alors, cela revient au modèle économique dont nous avons parlé plus tôt. Ainsi, dans la conception orientée domaine, nous avons le cœur, le support et le générique. Ainsi, vos domaines fondamentaux sont les parties de votre système où plus vous investissez, plus le retour est important. Les domaines de soutien sont là pour vous permettre d'optimiser vos domaines fondamentaux. Ils fournissent des fonctionnalités qui n'ont pas un grand retour sur investissement pour votre entreprise, mais elles sont nécessaires, elles sont limitées à votre domaine. Et puis les domaines génériques, ce sont
[00:30:10] des choses que vous verrez dans de nombreux domaines différents. Les exemples évidents sont les services d'identité, les services de paiement, etc.
[00:30:19] Ici, nous pouvons également parler du rôle que ce contexte délimité joue dans le modèle commercial. Donc, ce contexte délimité représente-t-il un ensemble de fonctionnalités que les clients paient directement ? Ce contexte délimité représente-t-il un ensemble de fonctionnalités qui attirent les gens vers le produit mais ne génèrent pas de revenus ? S'agit-il de conformité ou d'autre chose ? Ces quatre exemples ici ne sont que euh, quelques suggestions, vous pouvez, vous pouvez en quelque sorte mettre n'importe quoi ici. Et puis l'évolution parle de la terminologie de la cartographie de Wardley. Alors, comment ce contexte évoluera-t-il au fil du temps et à quel niveau se trouve-t-il maintenant ? Est-ce une marchandise ? Est-ce quelque chose de personnalisé, de nouveau et d'aventureux ?
[00:31:07] Et cela nous aide à penser à la vision à long terme.
[00:31:14] Alors j'ai un exemple rapide ici de ces rôles de modèle économique. Donc si nous pensons aux moteurs de recherche comme euh Google ou Bing,
[00:31:22] la recherche elle-même, nous ne payons pas pour utiliser la recherche sur Google, c'est une fonctionnalité gratuite, c'est une fonctionnalité d'engagement. La publicité est la façon dont l'entreprise gagne de l'argent, c'est le revenu. Et puis le RGPD concerne la conformité.
[00:31:37] Maintenant, ce qui est intéressant, c'est que vos domaines fondamentaux ne sont pas toujours vos capacités génératrices de revenus.
[00:31:48] Donc, dans l'exemple de la recherche Google, euh, c'est la recherche qui nous amène à Google. S'il n'y avait pas de recherche, nous n'irions pas là-bas pour les publicités. Peut-être que certains le feraient, mais je pense que la plupart d'entre nous n'utiliseraient probablement pas Google si ce n'était que des publicités et aucune recherche. Ce qui est essentiel, c'est ce qui rend votre entreprise différente, pas ce qui vous rapporte des revenus.
[00:32:13] Et si vous n'avez jamais vu la cartographie de Wardley auparavant, ce diagramme la rend très compliquée et effrayante. Mais ce n'est en fait pas si effrayant. Et euh, je pense que s'il y avait un outil ou une technique que je recommanderais à presque tout le monde, ce serait probablement la cartographie Wardley. Si ce n'est pas pour la technique de cartographie de Wardley elle-même, juste le concept de penser à la façon dont les choses évoluent au fil du temps, comment ces différentes parties de mon architecture évolueront-elles au fil du temps ? Et cela peut nous aider à faire des choix comme nous ne pouvons pas acheter cette chose. prêt à l'emploi maintenant, il n'y a pas de produits de base disponibles, mais nous pensons qu'il pourrait y en avoir un dans un ou deux ans. Alors construisons-le de manière à pouvoir le remplacer par une solution prête à l'emploi. Ou bien nous pourrions voir que notre domaine central va bientôt devenir une commodité, et cela nous dit quel est le prochain domaine central ? Dans un ou deux ans, cette chose ne sera plus spéciale. Quel est l'avenir ?
[00:33:17] D'accord, ensuite nous arrivons à l'interface.
[00:33:21] Ainsi, un contexte délimité est une boîte. Il reçoit des requêtes, des commandes et des événements entrants, et des requêtes, des commandes et des événements sortants. Une requête est une demande d'information.
[00:33:33] Donc, un contexte délimité A pourrait demander à un contexte délimité B : donnez-moi la liste de tous les utilisateurs qui n'ont pas payé leur facture. Une commande est un message ou une instruction indiquant à un autre contexte délimité de faire quelque chose. Hey, supprimez mon compte.
[00:33:49] Ou ajoutez cet article au panier, par exemple. Et un événement est une notification que quelque chose s'est produit.
[00:33:57] Et je pense que ce, ce euh, ce modèle, ces concepts sont une bonne façon de penser à toute la communication qui entre et qui sort.
[00:34:10] Oui, euh, pas grand-chose de plus à dire vraiment, je pense que je vais passer à autre chose. Je suis sûr qu'il y avait quelque chose que je voulais dire là, mais j'ai oublié maintenant.
[00:34:18] Donc de toute façon, en utilisant le langage des commandes, des requêtes et des événements, nous pouvons cartographier cela d'une manière plutôt visuelle. Donc la communication entrante sur le canevas montre les choses qui arrivent et la communication sortante montre les choses qui partent. Et nous pouvons voir des modèles ici. Nous pouvons repérer des modèles évidents comme une communication verbeuse avec un autre contexte délimité. Il envoie une requête, il envoie une requête, il envoie une requête, puis il envoie une commande. Comment pouvons-nous réduire ces quatre messages en un seul message pour réduire le couplage entre ces systèmes. Lorsque nous parlons de messages, nous ne parlons pas d'un bus de messages ici. Nous ne parlons pas de Kafka ou de quelque chose de ce genre. Nous parlons simplement de représenter chaque communication entre différents contextes délimités d'une manière logique. Quelle est l'intention de cette communication ? Et donc les commandes, les requêtes et les événements s'y adaptent parfaitement. Et je pense que même si vous n'êtes pas développeur ou architecte, vous devriez quand même pouvoir participer à ces conversations. Cela devrait toujours avoir un sens pour vous. Il s'agit d'architecture de domaine, d'architecture d'entreprise. Il ne s'agit pas d'architecture logicielle. En fait, ces messages pourraient être entre des personnes qui se parlent dans l'organisation, presque. Nous essayons de nous éloigner du logiciel à ce stade, de penser à l'architecture du domaine.
[00:35:48] Hum, j'ai quelques astuces ici. Quand vous, quand vous, donc je parlais du canevas comme d'un pari, une façon de visualiser votre pari. Et donc, quand vous visualisez des choses, vous pouvez repérer des motifs évidents, vous pouvez leur appliquer des critiques, des critiques évidentes. Donc le nommage, vous pouvez regarder tous les messages sur votre canevas, la description et le nom, et juste réfléchir. Est-ce que tous ces mots ensemble ont du sens de manière cohérente ? Utilisons-nous le même mot de manière constante ? Utilisons-nous deux mots pour décrire la même chose ? Parlons-nous de taxes et de cartes de crédit alors qu'ils ne vont pas ensemble, etc. ? Nous pouvons aussi dire, que se passe-t-il si nous inversons le type de message ? Et si nous remplacions cette commande ici par un événement, comment cela impacterait-il la conception ? Quel est l'impact sur le couplage dans le logiciel et les équipes ? Et nous pouvons examiner l'encapsulation en essayant de réduire la taille de l'interface pour réduire la complexité globale.
[00:36:45] Sur le canevas, nous montrons également les collaborateurs. Et typiquement, il y a quatre types différents ici. Un contexte délimité peut communiquer avec un autre contexte délimité, un système externe comme Salesforce ou Stripe. Par exemple, vous pouvez parler à une application front-end/mobile. Ou vous pouvez avoir des utilisateurs interagissant directement avec votre contexte délimité. Et comme je l'ai dit plus tôt, généralement, les collaborateurs sont des dépendances entre les équipes. Donc l'équipe qui possède ce contexte et l'équipe qui possède le site web public, il y a une dépendance ici. Et si nous voyons trop de dépendances, nous pouvons déjà avoir un signe d'avertissement avant de commencer à construire ce contexte, il semble trop grand. Nous avons trop de dépendances ici. Cette équipe peut-elle gérer les relations avec ces cinq autres équipes différentes ou est-ce que ce sera une charge cognitive trop lourde ? Je pense que Matthew Skelton en parlera, je crois qu'il est jeudi.
[00:37:45] Encore une fois, nous pouvons examiner les collaborateurs et appliquer ici des modèles de critique courants. Combien de dépendances ? Nous pouvons remettre en question chaque dépendance, que faudrait-il pour supprimer cette dépendance ? Nous pouvons regarder la loquacité.
[00:38:07] Très bien, donc maintenant nous arrivons à quelque chose qui est, euh,
[00:38:12] donc ça s'appelle la cartographie contextuelle. C'est dans la conception axée sur le domaine depuis les débuts, dans le grand livre bleu. Et la cartographie contextuelle essaie de décrire la relation entre le contexte délimité et entre les équipes. Il y a donc un élément technique ici et il y a aussi un élément organisationnel, et cela nous aide à identifier les problèmes en amont.
[00:38:34] Donc un modèle ici est un partenariat.
[00:38:37] Un partenariat, c'est lorsque deux équipes travaillent ensemble, donc deux équipes, elles possèdent deux contextes délimités, un contexte délimité chacune, et elles travaillent ensemble vers un objectif commun. Nous avons des modèles comme le conformiste,
[00:38:52] qui dit, mon contexte délimité va adopter le modèle de domaine de votre contexte délimité. Parce qu'il y a trop d'efforts pour traduire de votre monde à mon monde. Nous avons donc un tas de ces modèles et nous pouvons les montrer sur le canevas. Donc, pour chaque collaborateur, nous pouvons voir le type d'intégration technique et la relation d'équipe. Donc une chose que nous pourrions dire est que si un contexte délimité collabore avec six autres contextes délimités,
[00:39:24] et qu'il a un partenariat avec chacun d'eux, cela signifie que cette équipe a un partenariat avec six autres équipes.
[00:39:31] Et un partenariat, c'est travailler vers des objectifs communs. Donc, aller aux réunions partagées, peut-être avoir un backlog partagé, beaucoup de cérémonies partagées, c'est un très haut niveau de collaboration et de coordination. L'équipe ne peut probablement pas faire trop de travail. Si quelqu'un ici a entendu parler des typologies d'équipes, vous verrez qu'il y a beaucoup de chevauchement ici. Ainsi, le modèle de partenariat de la conception orientée domaine est similaire au modèle de collaboration des typologies d'équipe. Les typologies d'équipes ont un mode de collaboration X en tant que service, un mode d'interaction dans la conception orientée domaine, ce qui est similaire à un service hôte ouvert. Donc il y a un certain chevauchement ici. Donc, si vous le souhaitez, vous pourriez utiliser les modèles de typologie d'équipes ici et non les modèles de conception axée sur le domaine.
[00:40:23] Nous arrivons ensuite à la section des décisions commerciales du canevas et, comme je l'ai dit plus tôt, ce sont les règles commerciales.
[00:40:32] Alors, premièrement, cela nous aide à déterminer combien de règles complexes nous avons ici. Quelle est la complexité locale de cela ?
[00:40:41] Nous pouvons déterminer quelles règles sont créées par le logiciel et quelles règles, quelles décisions sont prises par un utilisateur. Nous pouvons commencer à analyser quelles informations ce contexte délimité a besoin d'autres contextes délimités pour prendre cette décision. Combien de dépendances avons-nous afin d'appliquer cette règle métier ? Donc cette règle pourrait être un signe, cette règle pourrait être la cause de trop de dépendances. Et puis nous pouvons aussi demander, qui se soucie des résultats de cette décision ? Parce que quand on parle de qui, on parle d'autres équipes et d'autres contextes délimités. Plus le contexte se soucie de cette décision, plus nous avons de couplage côté communication sortante.
[00:41:25] Nous avons également quelques types de règles ou de décisions différents.
[00:41:30] Donc certaines règles que nous appliquons en amont pour des règles métier qui ne peuvent jamais être violées. Parfois, nous ne pouvons pas empêcher les situations de se produire, nous avons des règles de compensation qui s'appliquent après coup.
[00:41:45] Alors j'ai quelques exemples ici.
[00:41:48] Donc un invariant dans la terminologie de la conception orientée domaine est que tous les noms d'utilisateur doivent être uniques. Il n'est jamais acceptable dans le système que deux utilisateurs aient le même nom d'utilisateur, cela briserait tout dans notre système. Cela violerait toutes nos règles de sécurité et de confidentialité et cela ne peut tout simplement jamais arriver. Maintenant, une autre règle est que le solde de votre compte bancaire ne peut pas être négatif. Cependant, il n'est pas toujours possible pour les banques d'appliquer cette règle en raison de contraintes externes. Alors, quand j'avais 16 ans, je crois, ou 15 ans, euh, j'avais un compte bancaire, comme un compte bancaire d'adolescent, et ils m'ont dit, oui, nous avons une règle commerciale, Nick, tu ne peux pas être à découvert sur ton compte bancaire.
[00:42:33] J'ai pensé que c'était cool. Sauvez-moi de moi-même. Et puis un jour, j'ai reçu une lettre par la poste, Salut Nick, ce compte bancaire que nous t'avons donné où tu ne peux pas être à découvert, tu es à découvert et tu as 30 jours pour nous rembourser et si tu ne le fais pas, nous fermons ton compte bancaire. Ils ont fermé mon compte bancaire. Donc le point ici est que parfois vous avez une règle mais vous ne pouvez pas toujours la faire respecter, vous devez appliquer une action de compensation après. Ainsi, le canevas nous aide à réfléchir à chacune de ces règles et si nous appliquons des invariants initiaux ou des politiques de compensation pour les faire respecter.
[00:43:14] Nous avons ensuite le langage omniprésent. C'est donc un glossaire de termes de domaine qui n'existe que dans ce contexte délimité. Chacune des phrases ici, la définition ne s'applique que dans ce contexte délimité, nous pouvons avoir les mêmes phrases dans des contextes différents et elles peuvent avoir des significations différentes. Donc ma tomate n'est pas votre tomate, vous possédez la définition ici.
[00:43:36] Et cela nous aide à simplement capturer quels sont les termes clés dans ce contexte que nous pensons que tout le monde devrait connaître, quelles sont les définitions que nous devons clarifier. Et aussi, l'un des avantages de la conception pilotée par le domaine est que nous maintenons le code en utilisant le même langage que celui que parle l'entreprise. De cette façon, il est plus facile pour les développeurs de parler au métier, de prendre ces exigences et de les implémenter dans le code parce que c'est le même langage. Donc cette section de langage omniprésent nous aide à capturer la terminologie importante du domaine. Et nous pouvons identifier ces problèmes comme la tomate où elle a plusieurs significations.
[00:44:14] Et puis les rôles de domaine. Donc les rôles de domaine sont un peu flous pour le moment, ce n'est pas un concept clairement défini. Mais cela nous aide à réfléchir au type de comportement que ce contexte délimité a. Donc Alberto Brandolini, il parle de ces trois types différents. Donc il dit que certains contextes délimités consistent à créer une spécification.
[00:44:40] Ils décrivent quelque chose qui doit être fait. Cette description est ensuite transmise à un contexte qui l'exécute, il gère le processus métier. Et puis nous avons d'autres types de contextes qui gardent une trace des choses qui se sont passées et ils observent l'exécution et ils analysent simplement ce qui se passe. Donc un exemple ici était quand je travaillais dans le, euh, quand je travaillais dans le marketing. Nous avions donc un contexte pour la création d'une campagne publicitaire. Vous spécifiez votre public cible, le montant que vous êtes prêt à enchérir, la date de début de la campagne, etc. Cette spécification est transmise au gestionnaire de campagne publicitaire, qui exécute votre campagne pendant une certaine période.
[00:45:25] Et il existe également un contexte qui surveille votre campagne publicitaire et analyse ce qui se passe et calcule comment nous pourrions optimiser cette campagne publicitaire.
[00:45:37] Donc, le simple fait de réfléchir au type de contexte délimité que nous avons peut nous aider à voir des concepts qui ne devraient pas être ensemble. Donc si nous avons brouillon et exécuter ensemble, peut-être qu'ils devraient être des contextes séparés. Mais en tout cas, nous voulons découpler ces parties du code au cas où elles seraient séparées à un moment donné dans le futur.
[00:46:01] Et quelques-unes des heuristiques ici sont que plus vous avez de rôles, évidemment, plus c'est un grand signe d'avertissement, cela indique une complexité locale.
[00:46:13] Je suppose que les rôles correspondent à l'interface de votre contexte ?
[00:46:20] Donc si vous dites que votre contexte est un contexte de brouillon, Je ne veux pas voir des tonnes de messages sur la communication entrante et sortante concernant l'exécution d'un processus métier. Il y a une incohérence là, et c'est une odeur de conception que nous devons approfondir et explorer plus en détail.
[00:46:40] C'est à peu près tout pour le moment, du moins en termes de temps, alors je veux juste vous montrer rapidement cette recette pour trouver de bonnes limites, pour créer de bonnes limites.
[00:46:50] Donc, comprend le modèle économique.
[00:46:54] Explore le domaine. Identifiez vos tomates et où elles ne sont pas vraiment des tomates ou différents types de tomates.
[00:47:02] Ensuite, nous pouvons commencer à chercher des options, comment pouvons-nous regrouper ces concepts de domaine en formes ou en couleurs ou en combinaisons ? Nous devons garder à l'esprit la complexité locale versus globale. Et puis, pendant que nous faisons cela, nous devons réfléchir à l'impact sur l'organisation. Quelle est la complexité sociale ici ? Et ces contextes délimités donnent-ils un but aux équipes qui les possèdent ?
[00:47:30] Et puis, comme toujours, pensez à votre conception comme à des paris. Vous faites des paris sur l'avenir, placez vos paris et ensuite surveillez ces paris. Ces paris se déroulent-ils comme vous l'aviez anticipé ou avez-vous plus de couplage que prévu ? Alors juste une dernière chose ici. J'ai rassemblé une foule de ressources ici. Donc, le livre sur les typologies d'équipes, le livre sur le modèle économique, le journal de conception organisationnelle, et quelques livres que j'ai trouvés utiles sur ce sujet.
[00:48:00] Il y a aussi le meetup virtuel DD et la conférence sur le domaine Z l'année prochaine.
[00:48:06] Et c'est tout. Je vais maintenant repasser la main pour euh

Transcription (Traduit)