Alberto Brandolini - Domain-Driven Design in Productland

[00:00:04] Bonjour, bonjour, bon retour. Nous euh recommençons, euh deux autres conférences avant la fin de la première journée.
[00:00:20] Et maintenant, nous recevons, nous accueillons euh Alberto Brandolini. Peut-être le connaissez-vous déjà. Nous sommes ravis de l'avoir à nouveau à la conférence Flow. Je crois que la dernière fois, euh Alberto n'a pas pu venir. Donc, très heureux qu'il soit ici avec nous aujourd'hui et nous allons entendre des histoires sur le DDD dans le monde des produits.
[00:00:48] Merci.
[00:00:55] Euh, eh bien, merci d'être ici. C'est euh euh une expérience compliquée pour moi. L'histoire, enfin, à propos de moi, vous savez probablement quelque chose, un peu de l'event storming et et la chose, beaucoup sur le Domain-Driven Design. Mais ce n'est pas la chose la plus importante, la raison la plus importante d'être ici. Alors, la raison, maintenant je n'ai pas à marcher. Euh, la raison euh derrière cette cette conférence est euh, eh bien, beaucoup de gens essaient d'appliquer les idées du Domain-Driven Design dans un scénario différent comme euh l'espace produit. Et je voulais l'explorer. Et euh, et il s'est avéré que c'était un trou de lapin absolument énorme. Donc, la première fois que j'ai soumis cette conférence, la portée était très, très générique et j'ai fini par avoir environ quatre fois plus de matériel nécessaire pour donner une conférence. Et c'était, oui, il y a un an, plus ou moins.
[00:01:54] Et ils ont aimé le titre ici. Alors, j'ai réessayé et puis j'ai soumis à nouveau, j'ai réécrit toute la conférence et j'ai fini avec beaucoup plus de matériel. Donc, c'est mon problème et c'est la chose que j'essaierai de gérer, de maîtriser pour toute la pour toute la conférence. Donc, en parlant du point de départ, nous parlons du développement de produits et nous parlons du Domain-Driven Design. Et c'est comme mélanger des pommes et des oranges, euh, et j'ai besoin de clarifier un peu. Juste, beaucoup de gens essaient de faire du Domain-Driven Design, malheureusement. Je suis un peu analyste. Le Domain-Driven Design est probablement en train de se généraliser, mais il y a quelque chose que nous devons corriger. Euh, quelques outils de réflexion sur la notation, j'essaierai d'appliquer quelques principes. Euh, l'un est de rendre l'implicite explicite. Dans certains endroits, comme la discussion de surface, ce n'est tout simplement pas suffisant. L'autre chose qui arrive souvent est, oh, ce n'est pas exactement mon contexte, ça dépend. J'essaie de rendre la dépendance finale, la chose qui dépend visible avec cette flèche plus, oui, quelques idées pratiques là où je peux. Maintenant, combien d'entre vous sont déjà familiers avec le Domain-Driven Design ?
[00:03:08] D'accord, la moitié de l'audience. Un récapitulatif très, très rapide de différentes perspectives. Euh, le Domain-Driven Design, en termes de philosophie, est vraiment basé sur l'apprentissage continu, essayer de comprendre la complexité plus profonde d'un domaine et essayer de le faire de manière collaborative. Eh bien, ça semble vraiment cool. Il y a quelque chose de vraiment spécifique concernant la conscience linguistique, comme euh nous ne faisons pas confiance au langage, nous l'utilisons comme un outil, mais nous savons que nous avons besoin de quelque chose de plus sophistiqué. Et les idées originales sont le langage omniprésent et le contexte délimité. En termes de stratégie, il y a l'idée de se concentrer là où ça compte vraiment, car faire de grandes choses là où ça n'a pas d'importance, eh bien, c'est une perte de temps et aussi euh d'argent des parties prenantes. Euh, en termes d'architecture, pendant de nombreuses années, les livres originaux, ils donnaient l'impression que le Domain-Driven Design était une approche architecturale. également assez prescriptif, comme si vous vous souvenez de toutes les discussions sur les entités, les objets de valeur, les agrégats, les services et le fait de faire de l'orienté objet très propre. Ce n'est pas toute l'histoire pour l'instant. Toute l'histoire derrière cela était euh que nous avions besoin d'une architecture pour une réécriture continue et c'était la seule disponible en 2004. Maintenant, nous avons un peu plus d'options. En termes de conception, l'un des principes clés est
[00:04:28] ne pas avoir un seul modèle, mais avoir plusieurs modèles spécialisés pour différentes finalités. Et cela correspond très bien à la notion de travailler au sein d'une grande organisation, euh qui a de nombreuses finalités, comme la facturation est différente de la gestion des expéditions et euh et euh des ventes et et aussi peut-être quelque chose pour d'autres départements. Différentes finalités, différents besoins, modèles indépendants. Et en termes d'implémentation, il y a un fort accent sur la construction de blocs de construction robustes. Ok, de bonnes choses.
[00:04:58] Voyons comment ça s'adapte. Euh, du côté du produit, c'est là que je suis un peu un novice. Je veux dire, je ne suis pas exactement le dernier à rejoindre la discussion, mais en même temps, ce n'est pas d'où je viens, je viens du développement de logiciels. Et donc il pourrait y avoir une simplification excessive de ce qu'est une perspective produit. Pour moi, c'était l'autre côté. Et euh, je ne pouvais pas le faire rentrer dans les catégories. Mais il y a beaucoup de discussions sur le fait d'avoir une stratégie de base, de se lancer dans des expériences, de se concentrer sur la valeur et aussi sur différentes interprétations du terme design. Pas tellement sur le langage, l'architecture ou l'implémentation. D'accord. Jusqu'ici tout va bien. Alors, la première chose que j'aimerais aborder est l'état d'esprit.
[00:05:49] Les deux parties semblent maintenant être animées par la curiosité et l'approche commune semble être l'apprentissage continu. Nous voulons apprendre sur le domaine, nous voulons apprendre sur les biens de nos clients, nous voulons grandir ensemble, être meilleurs grâce à l'apprentissage continu. Semble facile.
[00:06:09] Sauf que, le premier problème que nous avons rencontré dans cet espace était : qui apprend ? Quand je dis qui apprend, c'est le premier conflit lorsque nous essayons d'appliquer le Domain-Driven Design dans une organisation produit. Ou lorsqu'un état d'esprit produit essaie d'approcher une équipe DDD, c'est euh
[00:06:31] nous essayons d'apprendre ensemble, nous avons différents ateliers avec différentes techniques, programmés à des moments différents et parfois la partie prenante ne peut pas être disponible pour les deux ateliers et cela semble redondant. Même si le DDD a proposé des idées comme la modélisation pour et les outils de modélisation collaborative comme, eh bien, l'event storming, le domain storytelling et ainsi de suite, eh bien, nous avons déjà fait l'atelier parfois. Aussi, souvent, c'est motivé par qui a le plus gros euh budget avant de commencer. Et euh et donc le sentiment est euh dans de nombreuses entreprises de produits, oh, nous avons déjà terminé l'apprentissage. Et ceci est un plan de conception. C'est ce que nous obtenons et euh et même si l'état d'esprit est le même, il y a d'autres blocages sur le chemin. Euh, aussi, sans parler du problème venant d'en haut d'une certaine manière. Comme euh les cultures des personnes étaient différentes. Et dans euh dans de nombreuses universités, les leçons qui étaient enseignées, surtout aux jeunes designers ou développeurs, étaient quelque chose comme tu fais du bon travail, tu devras dire aux autres quoi faire. Et cela se produit des deux côtés, pas exactement le meilleur endroit pour démarrer une collaboration. Euh, Donc, ce que nous avons découvert, surtout dans les endroits où les gens venaient de milieux différents, mais aussi parfois de fournisseurs différents ou de tous ces apprentissages ségrégués. Je fais cette recherche utilisateur et je partage juste le résumé, ce qui ralentit tout. Nous essayions d'apprendre quelque chose avec les experts du domaine, d'autres personnes essayaient d'apprendre quelque chose de très similaire mais pas exactement la même chose avec l'expert et cela créait un ralentissement de la disponibilité de l'expert.
[00:08:22] Sans compter que l'idée d'expert, si vous êtes dans le domaine du produit, pourrait être légèrement différente.
[00:08:29] Et c'est beaucoup plus intéressant, si vous pouvez jouer à expérimenter dans cet endroit, euh, pour, euh, oui, faire de l'apprentissage interdisciplinaire. Et j'ai mentionné l'event storming parce que c'est mon bébé, mais ce n'est pas la seule chose. Je dirais que l'espace pour l'apprentissage interdisciplinaire est assez vaste et peut-être que des outils comme Miro sont beaucoup plus intéressants en ce sens que nous pourrions avoir de très nombreuses vues différentes au même endroit qu'une seule discipline. Ce que j'aime dans l'event storming, c'est que ça peut aider à avoir différentes perspectives sur le même atelier.
[00:09:07] Mais la chose ici est que cela exige, en partie, de l'état d'esprit, de laisser tomber certains de vos outils spécialisés et d'entrer dans un domaine où même la notation pourrait faire partie d'une négociation.
[00:09:21] Donc, en général, ce qui a fonctionné a d'une certaine manière résonné avec la présentation d'ouverture de ce matin de Sander. Comme euh nous avons essayé de créer un environnement où les conversations entre différentes disciplines se produisaient. Eh bien, intéressant, dans un scénario, l'un des outils les plus efficaces pour créer cette collaboration interdisciplinaire était d'avoir un canal Slack. sans personne du côté client, ce n'était pas exactement un environnement produit. Mais c'était une chose qui créait la sécurité pour une bonne collaboration entre les experts. Mais en général, nous avons commencé à abandonner l'exclusivité d'accès à de très nombreux outils. Tout le monde pourrait avoir moins de barrières pour parler avec des gens de différents domaines et aussi pour accéder à des outils euh euh qui étaient utilisés dans l'exploration.
[00:10:20] L'une des premières euh victimes de cette approche est simplement euh, eh bien, oubliez l'optimisation. Je veux dire, ce n'est même pas de l'optimisation, c'est généralement de l'optimisation locale. Si vous êtes l'équipe de conception, vous essayez d'optimiser la charge de travail de l'équipe de conception. Si vous êtes l'équipe de développement, vous essayez d'optimiser votre propre charge de travail. C'est sous-optimal dans l'ensemble. Il faut absolument voir les choses sous une perspective plus large. Alors, oui, laissez tomber, ça fait partie du jeu. Euh, un autre outil qui faisait partie de mes antécédents préférés, mais qui vient aussi de différentes sources, c'est que vous avez besoin de quelque chose pour rendre
[00:11:04] une collaboration solide sur des sujets complexes possible. Et les outils de visualisation à grande échelle euh sont vraiment de bons bons outils pour ça. Il y a quelque chose de vraiment intéressant dans l'idée d'Obea dans le livre, l'équation de la collaboration, euh mais c'est un exemple de quelque chose que nous avons fait dans un scénario. Euh nous avons toujours utilisé euh Miro ici, nous avons hybridé la notation. Donc, il y a quelque chose qui est une capture d'écran prise d'un site web, euh d'autres zones explorant euh la notation de modélisation de processus d'event storming. Plus beaucoup de validations, plus beaucoup de dénis de responsabilité comme ceci est notre compréhension actuelle du comportement de ce département.
[00:11:51] S'il vous plaît, aidez-nous.
[00:11:54] Euh, une attitude vraiment, vraiment faible, mais nous essayons de créer un endroit où tout est visible, surtout la connexion entre les différentes zones.
[00:12:04] Et mais il y a une autre chose qui était euh qui était euh intéressante. Comme euh tout le monde était motivé par la curiosité. Ça ne signifie pas que nous partageons la même mentalité. Alors, la vraie réponse à cette question est : non. Nous sommes curieux, mais notre curiosité est différente. Donc, nous n'arrivons pas exactement au même endroit, mais la conversation est importante. Qu'est-ce que je veux dire par là ? Je veux dire, en tant que personnes techniques, et tout le monde dans notre équipe du côté technique était vraiment très partial à essayer de trouver la solution parfaite au problème. en espérant que la solution serait un logiciel. Et c'est quelque chose de très difficile à enlever du cerveau du développeur, comme c'est ainsi que nous résolvons le problème, en écrivant plus de choses. Nous avons besoin de quelqu'un d'autre dans l'équipe. Alors, ne le faites pas seul, ne supposez pas que vous pouvez le faire, nous avons toujours besoin de toutes les différentes perspectives.
[00:13:00] Regardons toujours une partie du parcours d'apprentissage, parlons un peu de stratégie. Parce que l'une des choses qui a représenté un changement majeur de la perspective DDD à l'état d'esprit produit est le fait que si nous lisons une entreprise de bout en bout. C'est ce que nous faisons habituellement en grand, euh euh même en storming, nous essayons d'évaluer tout ce qui se passe au sein d'une ligne d'activité. touchant tous les différents départements. Et euh et cela nous permettra de découvrir ce qui pourrait être le plus grand goulot d'étranglement actuel pour l'organisation. C'est ce que nous faisons lorsque nous développons une solution logicielle pour une organisation. Donc, pas un logiciel personnalisé de produit. Quel est l'avantage pour les personnes DDD ? L'avantage est que le problème le plus important à résoudre est très probablement déterministe. Nous avons des indicateurs clairs de la chose la plus importante à faire ici et maintenant : résoudre ce problème. Les gens votent, les gens parlent de tout et sélectionnent quelque chose. J'ai, disons, une confiance extrême, peut-être pas dans la solution, mais dans le fait que si je résous ça, tout le monde sera content. Eh bien, c'est, c'est bon.
[00:14:20] Nous avons le privilège de ne poursuivre qu'un seul objectif. D'accord, ça disparaît quand tu travailles avec le produit. C'est juste que tu ne peux pas sélectionner ta cible sous forme d'oiseau, je vais attraper cet oiseau. Vous ne pouvez pas. Plus vous avez de clients potentiels, tout ce qui vous intéresse, ce sont les clients, l'argent, l'abonnement, pas exactement celui-là. Et ceci, c'est un grand changement de mentalité aussi pour l'équipe de développement. Donc, le développement de produits n'est pas déterministe, du moins pas autant que nous le voudrions. Et l'un des résultats possibles est, Oh, d'accord, pas de problème. Dis-moi juste ce que tu fais, tu choisis l'hypothèse, tu fais tes paris et euh et j'implémenterai ce qui est ce qui est important. Tu prends tous les risques. Et euh, ce n'est peut-être pas la meilleure attitude.
[00:15:15] L'autre chose est que nous aimerions être dans un endroit où nous faisons des expériences continues. Et ce n'est pas exactement à quoi ressemble un carnet de commandes de développement logiciel traditionnel. Et cela crée pas mal de tensions ici. Une tension est que nous voulons mener les expériences et nous voulons apprendre. C'était une surprise intéressante et décevante, décevante selon la perspective. Alors, bien sûr, on ne peut pas apprendre sans données. Vous avez besoin de résultats des expériences et vous voulez qu'ils soient mesurables. Et le problème est : d'où viennent vos données ?
[00:15:54] Et c'est là qu'une architecture différente pourrait faire une grande différence. Donc, c'est euh une histoire épurée d'un scénario réel, euh, nous nous avions besoin de détecter une situation où nous avions des transferts de réservation. Et nous avons dû travailler en intégrant une très ancienne architecture héritée, centrée sur la base de données. Et euh, eh bien, la réponse était celle-là. Nous n'avons pas de transferts, comme le transfert n'est pas une information clé dans notre domaine, ce n'est pas un concept dans notre domaine, nous l'avons dans le monde réel mais pas sur la base de données. Ok, excellente idée, nous pouvons exécuter une requête qui détecte s'il y a eu une annulation suivie d'une nouvelle réservation par le même client et gérée par le même vendeur. Et euh, et tout le monde a dit, oui, oui, super idée. Super, mettons-le dans les scripts quotidiens exécutés en fin de journée, en manipulant les données et en les rendant lisibles si nous devons détecter une annulation. Et c'est la conversation que nous avons eue. Et voici un instantané de moi en train de regarder et d'écouter cette conversation. J'étais complètement paniqué.
[00:17:11] Comme euh vous manquez un concept clé et vous créez une complexité accidentelle pour gérer cette information en aval. Maintenant, c'est complètement fou.
[00:17:24] Alors, l'un des endroits où le DDD peut réellement faire une différence dans l'espace produit. Si vous devez apprendre, plus vous pouvez capturer de manière déterministe le comportement de votre utilisateur, plus vos discussions seront claires, nettes et rapides. Donc, si vous avez un monolithe anémique, si tout est un crud ou joue avec des données en arrière-plan. Désolé. Euh, alors ce que vous devez faire pour comprendre ce qui se passe, c'est ajouter une couche d'interprétation, généralement en BI. Et cela conduit à des données discutables. Et ce douteux mène à des problèmes. Si vous avez des modèles plus riches, basés sur des événements,
[00:18:05] eh bien, ce que vous obtenez est quelque chose d'un peu plus sophistiqué. Moins sujet à interprétation. Et aussi, vous n'avez pas à recréer la logique, vous l'avez en tant que citoyen de première classe. Et cela conduit de manière moins coûteuse à des données incontestables. Petite alerte ici, si vous avez déjà des spécialistes à un poste donné et une masse salariale, il pourrait y avoir une inertie au niveau organisationnel. Oh, c'est ce que je fais, c'est ce pour quoi vous m'avez payé, alors nous continuerons à faire ça.
[00:18:38] Euh, mais euh, oui, quand j'ai réalisé ça, j'étais, oh, complètement paniqué.
[00:18:45] Chaque implémentation pourrait être bonne pour votre produit. Hmm, certaines implémentations sont meilleures. Peut-être pas dans la manière dont le produit se comporte, mais euh, eh bien, aussi là, je dirais en tant que goût personnel, mais les avantages pourraient se trouver dans des endroits en dehors du produit logiciel lui-même, mais dans l'observabilité du produit lui-même.
[00:19:09] Euh,
[00:19:12] L'autre chose qui était vraiment agaçante était euh si vous obtenez des données douteuses, alors tout votre cycle de discussion devient toxique. Donc, au moment où nous ne pouvions pas faire confiance aux données parce que quel est le pourcentage de
[00:19:29] erreurs potentielles dans notre interprétation du comportement en aval. C'était vraiment, vraiment si ambigu que la discussion a cessé de porter sur les données et a commencé à porter sur qui est responsable. Je fais ce travail depuis 10 ans, tu es le seul à soulever ce problème et euh, ce n'est pas exactement la discussion la plus agréable dans laquelle je voulais être.
[00:19:54] Alors, il y a un autre genre de guerre qui pourrait devoir être ouvert. Cela a à voir avec l'interprétation des données. Et euh, et plus nous avions de discussions à ce sujet, plus nous réalisions que les biais et les sophismes logiques étaient en fait le problème numéro un. Nous voulions avoir une discussion critique sur les données et le comportement que nous détectons, et ce n'était pas exactement facile.
[00:20:22] Et euh, parce que oui, la pression, parce que le pouvoir et ainsi de suite. Alors, s'il y a une raison de plus d'opter pour la soi-disant triade produit, c'est-à-dire d'avoir le commerce, l'ingénierie et le design dans la même discussion, c'en est une. Comme euh, cela aide à réduire l'impact des biais sur les choix stratégiques, cela aide à voir les choses sous différentes perspectives. Mais plus réalistement, cela augmente la probabilité d'avoir au moins un penseur critique dans la pièce. Dans les pires des cas, vous avez trois personnes. Pas un penseur critique. Hmm, ce n'est peut-être pas le meilleur endroit où être.
[00:20:20] Et parce que oui, la pression, parce que le pouvoir et ainsi de suite. Donc s'il y a une raison de plus de suivre ce qu'on appelle la triade produit, c'est-à-dire d'avoir le commerce, l'ingénierie et le design dans la même discussion, c'en est une, par exemple, cela aide à réduire l'impact des biais sur les choix stratégiques, cela aide à voir les choses sous différentes perspectives, mais plus réalistiquement, cela augmente la probabilité d'avoir au moins un penseur critique dans la pièce. Dans le pire des cas, vous avez trois personnes, pas un penseur critique. Ce n'est peut-être pas le meilleur endroit où être.
[00:21:05] Changer de perspective, encore. Donc, dès que vous collaborez, dès que vous collaborez avec l'expérience avec une équipe plus grande, alors le flux commence à devenir un problème. Ce n'est pas strictement un problème DDD, mais vous avez du flux, du flux au nom de votre conférence. Donc, un petit peu de contexte ici.
[00:21:31] Il y a beaucoup de discussions et j'ai pris ce billet de blog de Pavel Samsonov ici comme un représentant parce que c'est profond, c'est euh c'était aussi douloureux pour moi de le lire, mais euh ça touche une corde sensible. Donc du point de vue de la conception et de l'expérimentation produit, l'Agile semble être une cage. Et j'ai été à l'Agile depuis, oui, longtemps et non, non, non, nous étions censés être les rapides. Et euh alors qu'est-ce qui se passe ici ? Euh, beaucoup de discussions à ce sujet. L'article est très, très intéressant, même si je ne suis pas d'accord avec tout, mais je pense que la douleur est bien réelle. Et c'est l'une des perceptions qui est euh qui est en coulisses. Le fait est que cela renforce un problème en coulisses, qui est une sorte de culture tribale des différents côtés. Et c'est du côté du développement logiciel ou du côté DDD et aussi du côté de la conception, sans parler d'autres professions possibles qui rejoignent la discussion. Chaque côté a une manière préférée de faire les choses et ils peuvent être exposés à une interprétation pas exactement la meilleure des dogmes de l'autre côté. Alors, ce que nous voulions analyser, c'est juste de voir où nous en sommes actuellement, parce que les dogmes n'étaient pas exactement justes. L'un des paramètres était donc la réactivité de votre équipe est euh hum, dans certaines équipes, eh bien, nous avons cette idée avec l'expérience, d'accord, nous pouvons réaliser l'expérience d'ici la fin juillet, ce n'est pas exactement le meilleur endroit où être, mais il y a probablement beaucoup de dette technique en coulisses. L'intermédiaire qui pourrait être ennuyeux, comme nous pouvons passer en direct lors du prochain sprint, mais vous devez toujours attendre 15 jours ou deux semaines pour obtenir quelque chose. Et ce n'est pas ce que vous voulez pour une petite expérience pour remettre en question une hypothèse. Donc, cela pourrait être la cage Scrum classique en action. Euh, nous avons été dans un endroit où nous avions une équipe très intelligente qui pouvait lancer une expérience en une journée, à condition que les gens ne soient pas surchargés de travail supplémentaire, donc techniquement c'était faisable et la conception était robuste. Mais cela exige de bonnes pratiques et de l'intégrité, et ce n'est peut-être pas la chose la plus fréquente à trouver. Il y a des réalités, mais peut-être que ce ne sont pas les réalités qui se cachent derrière et cela pourrait alimenter ce tribalisme dont je parlais. Ce qui était pertinent pour moi, c'est que si votre conception est robuste, avoir des options pour les expériences devient plus facile. Ce dont nous étions vraiment fiers, c'était : d'accord, nous avons construit une infrastructure de cette manière et nous avons cette idée pour une expérience, d'accord, facile. Nous avons cette idée, d'accord, facile. Eh bien, cela nécessite un peu plus de travail sur l'interface utilisateur. Nous avons cette idée de cette expérience, d'accord, nous pouvons le faire. Donc les options étaient en place, la flexibilité était en place. Chaque fois que nous avions une petite négociation sur la manière de faire cela de manière sûre pour l'entreprise, pour le logiciel et pour les personnes impliquées, mais c'était toujours euh toujours faisable. Sauf que la plupart des discussions, si vous creusez, font référence à des équipes qui ne sont pas exactement dans cette position. Donc, disons, ne faites pas confiance à Internet, c'est peut-être le résumé de la discussion ici. Mais la partie la plus intéressante ici est d'essayer de trouver un moyen de briser les barrières. Cela offrira des options pour une meilleure collaboration entre les différentes parties impliquées. Jetons un coup d'œil à ce qui s'est passé sur notre euh tableau. Euh et le problème auquel nous sommes confrontés et je suppose que beaucoup d'entre vous sont confrontés si vous êtes dans cet espace, c'est juste qu'il y a tellement de préoccupations différentes à l'intérieur de l'espace physique ou logique en fait limité si vous passez en direct. Je suis toujours fan des tableaux physiques et peut-être que ce sera plus clair. Donc de gauche à droite, nous avons quelque chose qui sont juste des aperçus non structurés, de petites idées, comme euh, je pense que nous pourrions peut-être faire quelque chose de mieux sur la page d'abonnement. Ou la formulation n'est pas claire et blablabla, pas quelque chose de sophistiqué. Ou peut-être quelque chose de non structuré provenant du feedback client. Juste il y a il y a
[00:26:08] des sources d'information non structurées, il y a le chaos qui pousse l'information dans notre backlog. Nous avons besoin d'un moyen de structurer et de travailler là-dessus et il y a beaucoup de nombreuses idées. Celle que j'aime le plus est l'arbre de solutions d'opportunité, c'est plus ou moins comme ça que j'essaie de visualiser les informations de structure, comme euh il y a beaucoup d'idées, nous avons encore besoin d'un groupe de personnes qui y réfléchissent. À partir de maintenant, cela devient un flux un peu plus prévisible. Même si traditionnellement, euh, nous aurions une équipe de conception travaillant sur des fonctionnalités, puis fournissant des plans à l'équipe de mise en œuvre, à l'équipe de développement pour les mettre en production. Il y a beaucoup de place, sans parler d'une revue finale et euh après que le truc soit développé. Il y a différents éléments comme euh la refactorisation n'est pas une préoccupation pour les équipes de conception très souvent, même si c'est possible, pas partie de l'expérience, mais euh les fonctionnalités et l'expérience pourraient vivre au même endroit. C'est le problème ou l'un des problèmes. Si vous passez au numérique, vous ne verrez jamais cela. Toutes les informations qui font partie de la culture Kanban, les grands modèles visibles comprenant la contrainte, nous ne les voyons pas en ligne. Et euh parce que vous ne pouvez voir qu'un ensemble donné de colonnes à l'écran, d'accord, vous pouvez déplacer l'écran, vous pouvez faire défiler de gauche à droite, mais alors vous manquez l'impact. Et euh et c'est l'une des conséquences du travail à distance, dirais-je. Et euh et l'autre chose que nous avons perdue est, d'accord, l'un des flux est grand et il y a beaucoup de gens impliqués comme, mais si nous avons un goulot d'étranglement d'une personne, c'est presque invisible sur un tableau numérique. Vous avez besoin que la personne puisse dire, regardez, trop de choses m'impliquent, on dirait que tout repose sur moi et ça ne marche pas vraiment. Et euh oui, c'est une petite question pour tout le monde. À quel point vos outils numériques cachent-ils des choses ?
[00:28:15] Hum, nous avons travaillé un peu là-dessus, nous avons essayé de réduire, nous avons réalisé qu'avoir une configuration en cascade, euh la conception, puis euh, hum, l'implémentation n'était pas une bonne idée, et donc nous avons un peu réduit le flux. Nous maintenons toujours la séparation des éléments non structurés, la zone de conceptualisation fait partie du flux. Euh, ce que je voulais montrer, c'était euh, en gros, dans notre configuration, l'équipe de développement était impliquée dans presque tout, l'équipe de conception était impliquée dans presque tout, sauf le développement du euh logiciel réel. Et l'équipe commerciale faisait partie de la conception originale et ensuite des révisions des choses à réviser. Donc, pas mal, même s'il y avait une certaine tension. Ce qui était vraiment intéressant, c'est qu'en raccourcissant le flux, nous avons aussi changé la notion selon laquelle le design devrait toujours précéder le développement logiciel. C'est toujours l'idée principale, mais pas la seule façon et avant, ça pouvait être différent. L'autre chose qui était claire, c'est que les transferts explicites étaient un gaspillage. Surtout quand l'artefact était trop détaillé, nous n'en avions pas besoin. Et euh et aussi renforcer la possibilité de, oh, tu n'as pas compris mon plan ou quoi que ce soit. Donc, en pratique, une chose que nous avons faite et qui a très bien fonctionné, c'est euh réduire les frictions en travaillant en binôme et en ayant beaucoup de collaboration au lieu des transferts. travailler en binôme entre les disciplines afin que, d'accord, j'aie seulement besoin de ça, je n'aie pas besoin de tout le reste. Cela fonctionnait très bien. C'était, ça avait l'air vraiment bien, sauf lorsque nous avons rencontré une situation où la dette technique submergeait l'équipe technique, l'équipe technique n'avait pas le temps de participer à certaines activités. Donc, ils se sont retrouvés en aval à nouveau dans cette situation. C'était agréable de faire partie de cette discussion, mais pas surchargé par les vieilles choses. D'accord. Alors, des idées, euh, construire des outils de coopération. Rendre cela possible, supprimer les obstacles. C'est beaucoup plus difficile si vous le faites à distance, mais nous pouvons avoir des outils pour la coopération à distance. Vous pouvez faire de grandes choses avec Figma, vous pouvez faire de grandes choses avec Miro, euh, Slack et créer des endroits pour des conversations spontanées et aléatoires, euh, faites-les simplement, facilitez le contact avec les autres personnes. Et l'une des bonnes choses concernant l'environnement produit, c'est que d'habitude vous n'avez pas tant de fournisseurs externes, donc cela réduit déjà certaines des barrières. Et euh, petite note, la dette technique distrait l'équipe d'ingénierie, soyez sérieux à ce sujet. Ce ne serait pas le seul endroit où j'ai mentionné ce problème.
[00:31:14] Maintenant, c'est probablement la partie la plus difficile, ce qui signifie que la conception pilotée par le domaine est très, très spécifique et particulière concernant le langage, tandis que euh, eh bien, la gestion de produit ne s'en soucie pas vraiment ou peut-être y a-t-il quelque chose à propos du langage. Donc je dois et je dois aussi réaliser que certains des dogmes de la conception orientée domaine ne fonctionnent pas vraiment ici. Alors, l'une des idées clés de la conception axée sur le domaine était le langage ubiquitaire. Vous ne pouvez pas dire que vous faites du DDD sans le mentionner. Qu'est-ce que le langage ubiquitaire ? Le langage ubiquitaire vient de l'idée, de la réalisation que pour comprendre la complexité du domaine, nous parlons avec les gens.
[00:31:59] Il ne faut pas être un génie pour comprendre cela. Le fait est que, lorsque nous parlons avec des gens, nous utilisons un langage et nous faisons confiance au langage en pensant qu'il peut transmettre des informations claires et non ambiguës de votre cerveau au mien et vice versa. Eh bien, cela ne fonctionne pas comme ça.
[00:32:19] Le langage est un salaud digne de confiance, dirais-je. Il ne vous donne pas la précision dont nous avons besoin pour développer un logiciel. Euh, en matière de conversation, nous pouvons faire des blagues et parler de choses et ensuite accommoder l'ambiguïté. En matière d'implémentation, nous avons besoin d'une précision binaire. Les langages conversationnels n'ont pas cette précision binaire. D'accord, maintenant construisons-en un. Donc, toute l'idée des langages ubiquitaires, nous avons besoin d'un langage qui pourrait encore être utilisé en conversation, qui a la même précision qu'un langage d'implémentation, qu'un langage de programmation. Ce n'est pas quelque chose qui arrive spontanément, c'est quelque chose que nous fabriquons, martelons et affinons à chaque conversation. Nous essayons avec différents termes, nous choisissons celui qui fonctionne le mieux, qui fournit une meilleure compréhension, et nous améliorons notre langage. Et quand je dis notre langage, je veux dire dans les premières phases, l'équipe de développement essaie de capturer le plus de langage possible de l'expert du domaine. Dans la deuxième phase, l'équipe de développement et l'expert du domaine affinent le langage, injectant la précision qui n'aurait peut-être pas été dans le langage original. C'est un travail continu. Le résultat est un langage dédié à usage unique, où chaque terme n'a qu'un seul sens et une seule limitation : cela ne se produit qu'à l'intérieur d'une bulle spécifique appelée contexte délimité.
[00:33:58] D'accord, c'est la théorie et euh ça marche, c'est l'une des meilleures idées de la conception pilotée par le domaine, sauf que nous pourrions ne pas réaliser quelle est la fondation derrière cela.
[00:34:14] Donc l'autre le paradigme concurrent est ce qu'on appelle le langage canonique. Et c'était aussi ainsi que le langage ubiquitaire a été interprété pendant longtemps. Donc une seule langue partagée par tout le monde. C'est euh, c'est une bonne idée, euh, ça sonne comme euh, comme génial, comme si tout le monde devrait parler le même langage, sauf dans la communauté DDD, nous le savons très bien. Nous avons un problème, c'est mon cauchemar quand je voyage, et cela montre aussi que la race humaine a complètement échoué sur un problème très simple, comme comment trouver la norme commune pour deux, trois trous dans le mur. Et nous n'avons pas pu résoudre ce problème, c'est génial si vous construisez des adaptateurs, mais cela échoue aussi que cette idée de parler la même langue ne fonctionne pas. Et donc c'est mon résumé. D'accord.
[00:35:09] Et nous le savions, le DDD a dit : "Génial, soyons omniprésents là où nous le pouvons à l'intérieur du contexte délimité". Et aussi la persistance privée crée des bulles sûres afin que nous puissions faire de grandes choses dans ce domaine. Et au moment où nous avons commencé à décomposer le système bien avec les bonnes limites, alors nous pourrions faire de grandes choses. Nous avons un langage formidable, qui suscite des idées, nous avons la sécurité pour une évolution continue à l'intérieur de la bulle sans une négociation continue sur la nécessité de renommer cette table et des choses comme ça. Non, c'est en fait super. Ça marche très, très bien. Tout le monde est content. Et la bataille originale était entre la perspective canonique sur la base de données partagée. C'était des années de lutte dans la communauté DDD ou dans la communauté architecturale, non, nous ne partageons pas la même base de données. Nous sommes dans un espace local avec un langage ubiquitaire local et si nous devons transmettre des informations, les événements de domaine sont une bien meilleure idée. Et progressivement, on dirait que beaucoup de gens ont dit que, en fait, les contextes délimités sont meilleurs, alors allons-y. Je veux dire, je me battais dans cette bataille il y a 15 ans. Et maintenant, j'ai l'impression que tout le monde sait comme, oui, bien. Alors, victoire. Sauf que nous avons oublié au moins une chose et probablement deux. Nous avons oublié les utilisateurs externes. Je veux dire, travailler avec une solution logicielle au sein de l'organisation nous fait oublier que nous avions le privilège de parler avec les utilisateurs de manière non médiatisée, l'expert, les utilisateurs et les parties prenantes étaient souvent les mêmes personnes. Et cela créait le cadre idéal pour une conversation créant un langage ubiquitaire. Dans le langage de surface, oh, c'est une autre histoire. C'est euh, nous avons aussi oublié l'intelligence économique comme une autre force, mais ce n'est pas cette conversation. Les différentes forces sur le langage de surface par rapport au langage ubiquitaire sont en fait différentes. Donc, dans l'ubiquité, nous pourrions aller en profondeur pour essayer de comprendre toutes les intrigues, nous pourrions même injecter de nouvelles abstractions et des blocs de construction et modifier le langage des personnes avec qui nous parlons. Pouvons-nous faire cela avec les utilisateurs ? Eh bien, pas vraiment. Je veux dire, nous pouvons lancer de nouveaux termes comme tweet ou réel ou TikTok, c'est une possibilité. Mais expliquer des choses aux utilisateurs, ce n'est pas une bonne façon de vendre. Donc l'autre chose à propos du langage qui est vraiment différente, c'est que si le langage ubiquitaire est d'une précision massive, essayez de capturer l'essence d'un langage, le langage de surface est différent. Cela exige l'illusion de la simplicité et non une compréhension plus profonde des mécanismes. Ce n'est pas ce qui rend votre produit vendable. Alors, que se passe-t-il si vous voulez voir le langage ubiquitaire, pour montrer le langage ubiquitaire, ce n'est peut-être pas ce que vous voulez voir. Alors, même si dans le passé, au moment où nous avons commencé à avoir une conversation avec des gens dans le monde du design, on a eu l'impression que, oh oui, nous avons un concept très similaire. Non, ce n'est pas le cas. Les forces derrière le contexte délimité dans le langage ubiquitaire sont, oui, axées sur le langage. Ce ne sont pas les mêmes forces sur le langage de surface. Et essayer de leur faire croire que c'est la même chose, ne vous mène pas exactement là où vous voulez aller. Donc, l'une des choses sur lesquelles nous avons dû nous mettre d'accord, c'est qu'ils doivent coexister. Il y a un langage qui doit être optimisé pour l'engagement des utilisateurs et de nombreux autres langages qui pourraient avoir besoin d'être optimisés pour l'implémentation. Et nous devons clairement maintenir la distance entre les langues aussi petite que possible, mais nous ne pouvons pas réduire cette distance à zéro car ils ont des objectifs différents et ils seront tirés dans des directions différentes. Nous ne pouvons donc pas choisir un seul paradigme.
[00:39:16] Ce qui arrive si euh, eh bien, commençons par le langage de surface. La plupart des utilisateurs pensent en un langage plat et si nous tirons les enseignements des utilisateurs et de leur histoire, nous nous retrouverons avec un gigantesque Microsoft Access ou avec un euh monolithe plat qui mènera au couplage en suivant ce que font les utilisateurs. Les utilisateurs n'ont pas à comprendre la complexité du contexte délimité. C'est pourquoi ils paient pour le logiciel, pas pour connaître ce désordre. Euh mais nous avons tort aussi. Au moment où nous comprenons la complexité et la sophistication des langages en coulisses, nous pourrions nous dire, d'accord, eh bien, mettons-le dans l'interface utilisateur. Ne faites pas ça. Euh, parce qu'au moment où vous exposez toute cette complexité aux utilisateurs, eh bien, ce n'est pas l'outil que j'aimais. Ce n'est pas ce que je voulais. Je voulais quelque chose de plus simple et c'est un gâchis. Comme euh, euh, disons avoir Google agenda et au lieu de ça, genre, oh, d'abord tu dois me dire quel type d'événement tu es en train de gérer. Est-ce un rendez-vous ? Est-ce un dîner ou ceci Non, non, juste un événement où faire quelque chose, quelque chose de plus simple. Et euh les utilisateurs aimeraient avoir de la simplicité et euh nous devons comprendre la complexité. Nous avons des objectifs différents ici.
[00:40:38] Donc, euh, l'autre partie est euh toute cette capacité à élaborer un langage très spécifiquement orienté vient du fait que nous avons accès aux utilisateurs réels. Et nous pouvons aussi les forcer ou les éduquer à faire quelque chose de plus sophistiqué.
[00:41:00] Un petit interlude entre les deux, mais rapide. L'autre chose qui me tracassait à chaque fois que nous commencions cette discussion avec euh des gens dans l'espace de la conception axée sur le domaine, c'est que nous demandions juste, comme euh, combien de personnes ici travaillent sur un produit ? Oui, oui, beaucoup de gens. Oui. Et puis je demande, d'accord, combien de clients avez-vous ? toute cette capacité à créer un langage très spécifique et orienté vient du fait que nous avons accès aux utilisateurs réels et que nous pouvons aussi les forcer ou les éduquer à faire quelque chose de plus sophistiqué. un petit interlude entre les deux, mais rapide. L'autre chose qui me tracassait chaque fois que nous commencions cette discussion avec les personnes de l'espace de conception axée sur le domaine. Nous aimons demander, par exemple, combien de personnes ici travaillent sur un produit ? Oui, beaucoup de gens. Oui. Et puis j'ai demandé, d'accord, combien de clients avez-vous ? Et euh non, et la réponse a été que c'est un produit interne. Et nous ne faisons pas de projets, nous avons commencé à utiliser un état d'esprit produit et c'est une solution que nous faisons évoluer en un produit. Ou nous avons un produit qui a un client et nous allons en avoir deux rapidement. Tout cet espace n'est pas un espace produit. C'est mon point de vue sur la question. Et si vous avez zéro client, vous avez un rêve, pas un produit. Si vous avez un client, vous avez une solution, mais vous ne faites probablement même pas de conception pilotée par le domaine. Parce que ce n'est probablement pas important pour eux, c'est important pour vous, mais vous n'avez pas tout l'essentiel. Si vous en avez beaucoup, peut-être que vous êtes en charge. Alors vous pouvez faire pas mal d'autres choses. Si vous avez peu de clients, surtout si vous êtes dans l'espace B2B, alors vous avez des problèmes. C'est probablement l'espace le plus horrible dans le monde des produits, quand vous avez quatre ou cinq clients et surtout quand vous en avez un qui domine clairement. C'est ce que nous appelons l'anti-pattern Miranda. Si vous vous souvenez du diable s'habille en Prada. Et ce client dominant pourrait être euh, disons, une force toxique dans votre backlog parce qu'ils le peuvent. Ils pourraient abuser de votre backlog de manière très amusante et euh mais ce sont vos plus gros clients. Donc ils peuvent vous contrôler. Hum, en fait, je veux sauter celui-ci.
[00:43:03] Mais lentement. D'accord. Donc l'autre problème ici est est-ce que cette fonctionnalité est uniquement pour un client ? Je sais que c'est du B2B, je sais que c'est grand. Mais à quel point mon intégrité est-elle en train de changer ? Et euh, et à certains égards, cela faisait en fait référence à l'approche de Basecamp et à la philosophie derrière le remaniement, comme il existe des produits qui sont absolument agressifs quant au fait de ne pas être personnalisables. C'est un produit, c'est ce que vous obtenez, ne me demandez pas plus de choses. Et euh mais c'est c'était pertinent pour moi, genre euh quel est l'intérêt de faire un produit si on laisse d'autres personnes décider ? Je veux dire, tout ce qui concerne l'entrée dans l'espace produit, c'est de posséder sa propre stratégie, de faire ce que l'on pense être juste. Ne pas passer d'un seul patron à cinq patrons ou mille patrons. Ce n'est pas du tout le but. Alors, dans quelle mesure menons-nous, en faisant ce qu'ils nous disent de faire, et non ce que vous voulez être en amont ? C'est là que j'aimerais être. Mais la pensée produit implique de prendre des responsabilités. La victime de ce processus est en fait ce qui, je pense, est l'autre chose importante à aborder, à savoir l'idée d'intégrité de la conception. Donc, euh, c'est ce que j'écoutais chez Sander ce matin et j'ai dit que tout le monde avait une dette technique. Et je n'ai pas été assez rapide. J'avais vraiment envie de dire non. Je voulais être le seul dans la pièce à dire non, euh parce que euh parce qu'en fait je ne
[00:44:51] Je n'ai pas le sentiment d'avoir une dette, mais aussi je n'aime pas l'hypothèse que tout le monde a une dette à payer. C'est peut-être une chose très catholique, ou euh je ne sais même pas d'où ça vient. Mais il semble qu'il y ait un fardeau que chaque équipe de développement logiciel doit payer. Et je pense que ce n'est pas une bonne métaphore. Euh pour de nombreuses raisons, j'ai écrit un article de blog à ce sujet il y a quelques mois et euh et je pense que je pense que j'ai fait un bon point là-dessus. Mais euh, l'une des choses est que si nous parlons de la dette. une grande partie de la discussion tourne autour de, oh wow, mais nous l'avons fait, c'était un investissement, cela n'a pas rapporté et nous devons le rembourser et bla bla bla. Et puis nous finissons par essayer d'expliquer le concept de dette technique à nos parties prenantes commerciales. Tout cela est un gaspillage. Ce n'est pas leur problème, c'est quelque chose que nous devons gérer, mais c'est aussi, oui, humiliant parfois et utilisé, pouvons-nous mettre une histoire réfractaire dans notre backlog ? Non, ce n'est pas la bonne discussion, je ne, je veux dire, ça me fait me sentir mal quand je dis ça. L'approche que j'aime est de retourner la pièce. C'est probablement exactement la même chose avec un nom différent, mais j'aime l'idée d'intégrité de conception. Qu'est-ce que l'intégrité de la conception ? C'est juste à quel point la conception actuelle correspond à l'objectif actuel. Alors, les Italiens, stéréotypes. C'est une pizza, a un, oui, je dirais juste que ça correspond au but, aussi la même taille que l'assiette. Donc un bon point de départ. Ceci a clairement des problèmes d'intégrité de la conception. Quel est mon point ici ? Si c'est le mieux que vous puissiez faire, vous devriez probablement quitter votre emploi. Ou cela ne pourrait arriver qu'une seule fois, alors vous devez le réparer et vous assurer que ce que vous livrez à vos clients est la meilleure qualité que vous pouvez vous permettre, le meilleur point de qualité sur lequel vous pouvez vous fixer. Si vous avez, si vous savez qu'au même prix vous pourriez avoir un meilleur goût avec des ingrédients différents, eh bien, vous devriez les utiliser, il n'y a aucune raison de ne pas le faire. Il n'y a aucune raison de fabriquer un produit de qualité inférieure si vous savez comment le faire. Et c'est ce que vous devriez faire avec les produits, comme, oh, il n'y avait pas le temps. Il n'y avait pas le temps de cuire la pizza. Allez, eh bien, dans ce cas, il y avait trop de temps pour cuire la pizza. Mais ce n'est pas le propos. C'est une question d'éthique, d'une certaine manière. Et c'est une approche de conception différente du même problème qui pourrait être comparable. La pizza ronde est optimisée pour être mangée assise, si vous la faites chauffer, la manger chaude est mieux. La pizza carrée est optimisée pour la marche et peut être gardée au chaud plus longtemps et euh, c'est un produit différent, un segment de marché différent. Les deux sont bons. Sauf si nous recevons une demande comme « nous voulons un calzone d'ici la fin de la semaine prochaine », nous pourrions avoir un problème. Parce qu'avec la pizza ronde, c'est très facile de la retourner, de la plier à l'intérieur du calzone. Alors qu'avec une pizza carrée, bonne chance pour faire un calzone d'un mètre de long, ce n'est pas exactement là qu'il devrait être. D'accord. Donc, c'est en fait un point qui donne le vertige à beaucoup de gens, mais peut-être parce qu'ils ne sont pas là où ils devraient être. Et c'est là que j'aimerais être à la place, j'ai beaucoup utilisé les photos de Bruce Lee, et dans ce cas, même si je ne connais pas grand-chose aux arts martiaux. Mon point est que ma conception devrait être dans la meilleure position possible, la position de préparation dans de nombreux arts martiaux est celle qui vous donne le plus d'options pour réagir à une attaque imprévisible. Et c'est là où vous voulez être. Vous ne voulez pas commencer à vous battre dans cette position, vous avez déjà perdu. Vous ne voulez pas commencer avec cette dette technique. Vous aimeriez être exactement dans la position la plus probable pour saisir le plus grand nombre d'opportunités. D'accord, c'est exactement là que je veux que mon code soit. Alors, si votre modèle correspond à la compréhension de votre domaine, si vous n'avez pas d'écart entre votre perception et votre implémentation, c'est probablement votre meilleure position. Vous êtes dans la meilleure position possible pour répondre au changement. Et l'hypothèse que j'ai, si vous êtes là, et que vous avez un modèle ajusté, et que vous ajoutez une fonctionnalité, alors vous vous retrouvez avec un autre modèle ajusté. Je veux dire, ça ne prend pas grand-chose. C'est très difficile d'être là, au moment où vous y êtes, une attaque et je reviens en position de préparation, une autre attaque, je suis de nouveau en position de préparation.
[00:49:35] Je suis exactement là où je devrais être. Si je continue à traîner ma dette technique, je suis désespéré. Donc, beaucoup de produits, c'est un sentiment, pas des données solides, sont dans une position de succès, seulement parce que vos concurrents sont légèrement moins bons. Dit.
[00:49:55] Mais l'autre chose est que souvent on a l'impression de marcher dans la boue. en mouvement, ces gens le font en fait pour le plaisir. Mais j'ai vu de nombreuses équipes de développement logiciel, euh, exactement là, sans se rendre compte que, eh bien, il y avait une autoroute qui allait de cette ville à celle-ci et nous ne pouvions pas, nous ne pouvions pas y arriver. Et euh mais c'est très difficile de voir l'autoroute si on continue à marcher dans la boue. Alors, oh oui, mais nous avons encore toute cette dette technique à porter. Non, il y a une route à proximité.
[00:50:32] Le deuxième problème ici est que nous aimerions être prêts, mais nous ne savons pas à quoi nous devrions être prêts. Et euh et il y a beaucoup d'idées fausses qui, encore une fois, cela dépend. Il y a des endroits où il y a une feuille de route claire sur ce que vous aimeriez faire au cours des cinq prochaines années et euh cela pourrait être un gouffre en termes de fragilité. Euh si nous ne faisons rien, nous devons être prêts à tout, c'est là que vos architectes ont tendance à sur-concevoir en ajoutant des couches de direction car le client pourrait demander ceci, ces choses. Ils n'ont aucune idée. Ils se préparent totalement à des invasions extraterrestres ou à tout ce qui s'y apparente. Mais il y a quelque chose entre les deux, ce n'est pas tout noir ou tout blanc. est euh relativement prévisible.
[00:51:24] Euh mais ce dont nous avons cruellement besoin, c'est que si nous devons être prêts pour quelque chose, nous devons comprendre ce que ce quelque chose pourrait être. Et donc la ségrégation redevient un problème. Nous ne pouvons pas saisir tous les verbes possibles simplement parce que les gens l'ont mentionné. Et aussi, nous ne pouvons pas nous sentir coupables de ne pas saisir tous les verbes. La question est : pouvons-nous prédire ce futur ou non ? Ma perception ici, encore une fois, pas exactement des données, mais la perception est que vous avez vraiment beaucoup d'informations sur ce que l'avenir probable pourrait être. Vous pouvez toujours avoir des événements de type cygne noir. Vous pourriez avoir quelque chose comme une pandémie perturbant tout et rendant tout à distance ou un chat GBT changeant le monde apparemment. Mais beaucoup de choses sont déjà dans notre radar. Donc vous ne devriez pas être si surpris.
[00:52:20] Et euh, l'autre chose est que, même si nous pouvions prédire, nous n'aurions jamais de toute façon la force ou la possibilité de saisir toutes les opportunités possibles. Donc, encore une fois, cela nous ramène à ce que l'on appelle la triade du produit, c'est-à-dire que vous ne devez pas être guidé par le marketing, les affaires, etc. L'ingénierie a mis en place l'intégrité de la conception. Euh juste pour dire genre, eh bien, nous ne sommes pas faits pour un calzone, cette opportunité ne sera pas saisie.
[00:53:04] Exactement. D'accord. Donc dire non est une possibilité pas en mon nom. Et euh l'autre chose que j'aime, c'est l'intégrité de la conception, c'est difficile à construire et très facile à détruire ? Il faut très peu. Nous l'avons déjà mentionné, donc je pourrais aller un peu plus vite ici. Euh l'autre chose qui était pertinente dans de nombreux endroits était à quel point une bonne architecture offrait de l'optionalité. L'idée de contexte borné de multiples contextes bornés, chacun ayant un but spécifique, s'est avérée être un assez bon prédicteur de la possibilité de changement se produisant dans une seule bulle. Ainsi, même si le changement n'était pas entièrement prévisible, nous pouvions toujours en minimiser l'impact car il se produisait de manière prévisible à l'intérieur de la bulle. Une grande exception, le RGPD, tout le reste était beaucoup plus prévisible. Donc, une possibilité rapide était de se dire, d'accord, nous avons cette nouvelle idée pour une nouvelle fonctionnalité possible, où va-t-elle s'intégrer ? Va-t-elle s'intégrer dans notre bulle ? Devrions-nous étendre notre modèle, devrions-nous créer un nouveau modèle pour les nouvelles choses, devrions-nous créer un modèle externe pour cela ? Très rapides questions, euh, oui, je voulais mentionner cela, mais euh pas assez de temps pour euh pour creuser là-dedans. En termes d'implémentation, la dernière chose est euh La conception axée sur le domaine, elle porte l'attention sur la robustesse, sur les petits blocs de construction. Et euh et ça colle vraiment avec l'idée de toujours cuisiner et d'avoir un bureau très très propre. Et euh ça signifie construire et affûter vos outils. Non, il n'y a aucune raison d'être désordonné, il n'y a aucune raison d'être dans un restaurant ou une pizzeria et de demander chaque jour, où est l'origan, où est le poivre ? Vous devriez savoir, vous avez été là, ça devrait être rangé, oups, et être au bon endroit. Et euh donc les blocs de construction, principalement des objets de valeur mais pas seulement, s'avèrent être un bon endroit pour construire la robustesse, la composabilité, et pour éroder la complexité du système et préparer les gens à expérimenter. Oui. L'heure de fermer.
[00:55:28] Alors, je suppose, je suppose que j'ai transmis le sentiment que, d'accord, c'était un grand gouffre. Il y a beaucoup de choses. J'espère avoir pu fournir quelques aperçus. Premièrement, le dogmatisme et le tribalisme, oubliez ça. Il suffit d'essayer de collaborer avec les gens, d'apporter le contexte de certaines idées, toutes les idées ne sont pas garanties de fonctionner. L'intégrité de la conception, je pense que c'est probablement la chose la plus importante. Par exemple, cela vous donne des options, cela vous donne de la sécurité, cela vous donne le temps de participer à une discussion plus approfondie. Et euh faites-en une exigence clé, vous ne pouvez pas faire un produit en portant le fardeau de "nous avons toujours des rats dans la cuisine". Ce n'est pas dans les cartes.
[00:56:14] Vous n'avez pas besoin de l'architecture DDD pour chaque type de produit, je veux dire Excel fonctionne sur un système de fichiers. Vous n'avez pas besoin d'une base de données et puis donc il y a des variations. Mais une implémentation architecturale sophistiquée vous donne des données et des options. Mais le plus important est de briser les barrières entre les disciplines. C'est un gaspillage énorme. Nous parlons avec notre jargon local et nous n'allons nulle part. Alors, rendez les images disponibles, euh simplifiez la conversation et trouvez des moyens d'apprendre des autres disciplines et de collaborer.
[00:56:51] Et je dirais que la chose la plus importante est la dernière. On peut le faire seul, donc nous avons besoin d'aide et de collaboration. Et euh, eh bien, trois lapins valent probablement mieux qu'un seul. Alors, merci et désolé d'avoir volé les deux dernières minutes. Je serai là pour euh aujourd'hui et demain. Donc, toute question, euh, merci.

Transcription (Traduit)