Langage ubiquitaire au-delà d’un Bounded Context ?

Langage ubiquitaire au-delà d’un Bounded Context ?

Par Godefroy Clair

Langage ubiquitaire au-delà d’un Bounded Context ?

Depuis ses premiers développements, le Domain Driven Design a mis en avant l’importance du langage dans la réussite d’un projet. Cela dit, les informaticiens et les managers n’ont pas attendu le DDD pour comprendre que la communication est essentielle pour aligner les participants à un projet et éviter les incompréhensions ou même les tensions.

Alors en quoi le DDD va-t-il plus loin ? Il faut remonter au livre d’Eric Evans, Domain-Driven Design, pour comprendre l’originalité de cette approche et pourquoi le DDD fait du langage une clé fondamentale de son projet visant à unifier l’ensemble des étapes de conception d’une solution métier.

Pourquoi a-t-on besoin d’un langage ubiquitaire ?

Le DDD part d’un constat simple : il est impossible de concevoir un modèle métier pertinent sans une compréhension claire des besoins métier. Le design stratégique est une approche qui vous aide à appréhender ces enjeux pour focaliser votre énergie sur ce qui est véritablement stratégique pour votre entreprise. Il ne s’agit pas de se précipiter sur une solution, mais de prendre le temps de comprendre et de structurer le problème.

Le design stratégique clarifie les fonctions de l’entreprise en les divisant en domaines métiers, clarifiant ainsi les domaines et sous-domaines où se trouve son avantage compétitif tout en facilitant l’émergence d’une organisation efficace capable de prioriser les projets en fonction de leur valeur.

Cette organisation repose sur des équipes pluralistes où règne une collaboration étroite entre les experts métier et les développeurs. La collaboration entre ces deux groupes est fondamentale : elle permet une meilleure compréhension des besoins métiers et favorise l’émergence de modèles mentaux partagés.

C’est dans ce cadre que se fait sentir le besoin d’un langage précis, sans superflu et partagé par tous les acteurs du domaine (développeurs, experts métier, product managers…). Il est structurant, reflète profondément la compréhension du domaine et n’évolue que parce que la compréhension du besoin n'évolue que parce que le besoin change, ou parce que sa compréhension s'affine. C’est cela qu’on appelle le langage ubiquitaire.

Comment naît un langage ubiquitaire ?

Imposer ce langage ubiquitaire capable d’unifier modèle du domaine métier et design logiciel est plus facile à dire qu’à faire… Spontanément, les architectes ont tendance à laisser se créer - voire à encourager - une forme de ségrégation entre l’architecture logiciel et la modélisation métier.

Concevoir un modèle unique qui exprime des concepts métiers souvent complexes, tout en servant de lexique à la base de code semble ambitieux. Ne doit-on pas à un moment sacrifier les considérations techniques pour bien traduire le métier ou, au contraire, se résigner à abandonner des principes importants du design logiciel pour coller aux considérations du domaine ?

Pour éviter ces écueils, le DDD propose de construire le langage ubiquitaire en suivant quelques principes :

• Travailler par un processus itératif. Cela signifie commencer avec un modèle imparfait - même naïf - et progressivement enrichir ce modèle tout en éliminant les éléments superflus.
• Travailler selon un processus collaboratif basé sur des interactions fréquentes entre les experts métier et les développeurs.
• Pratiquer ce langage quotidiennement et avec discipline au sein de l’équipe : il faut utiliser les mots métiers et éviter au maximum les termes techniques. Cette pratique doit se retrouver dans les discussions mais aussi dans l’expression des besoins, le code, les tests, les modèles…
• Faire de chaque membre de l’équipe un expert métier à égalité des autres. Si les “vrais” experts métiers apportent la connaissance initiale, les informaticiens ont souvent des qualités pour déceler des biais dans le vocabulaire (par exemple des doubles sens).
• Expliciter la signification précise de chaque terme métier dans son contexte. L’équipe est capable de comprendre et d’expliquer chaque élément du contexte métier avec une grande clarté.

Lorsqu’il atteint un certain niveau de maturité, le langage ubiquitaire devient un levier essentiel pour aligner les modèles mentaux, affiner la compréhension du domaine, et soutenir une collaboration efficace afin de réduire la complexité métier.

Les limites du langage ubiquitaire

Cependant, l’approche DDD ne doit pas nous faire tomber dans le mythe de la Tour de Babel : contrairement aux idées reçues, il n’existe pas de langage ubiquitaire unique partagé par toutes les personnes d’une entreprise ou même à toutes les interactions entre le “métier” et les “développeurs” : le langage ubiquitaire cherche à résoudre un problème précis dans un contexte précis. Sorti de ce contexte, il risque de devenir contre-productif.

En effet, l’émergence du langage ubiquitaire est un processus complexe et il demande d’y mettre des limites spatio-temporelles :

• C’est un langage qui vit dans un espace restreint - son bounded context : il ne peut émerger que dans un périmètre resserré où les interactions sont limitées à un nombre défini de personnes ;
• C’est un langage qui naît et qui s'épanouit dans le temps long : il nécessite qu’on laisse le temps à l'équipe de s'approprier le bounded context. La nature humaine est ainsi faite que la répétition des concepts, la multiplication des points de vue subjectifs et leur dépassement par le débat sont généralement nécessaires pour arriver à la solution. Et même au-delà, le langage ubiquitaire demande de la patience : l’attente active ouvre des chemins, provoque des attractions et des décalages, dessine des occasions qu’il est très difficile de contourner.

Pour résumer, réussir à faire émerger le langage ubiquitaire et le modèle mental qu’il sous-tend fait appel à des capacités intellectuelles parmi les plus avancées de l’être humain. Pour décrire notre capacité à déconstruire la complexité et à l’expliquer de manière simple, le neurophysiologiste Alain Berthoz parle de “simplexité” : “l’art de rendre simples, lisibles, compréhensibles les choses complexes”.

Du rôle de la pomme dans la célèbre découverte de la gravité par Newton à celui de la barre chocolatée dans le développement du premier micro-onde par Spencer, l’Histoire des sciences et des techniques est gorgée d’exemples où cette simplexité n’a pu apparaître sans un ou plusieurs “coups de chance”. Si une entreprise cherche en quelque sorte à “industrialiser” ce processus, elle devra donc s’armer de patience.

Un autre type de langage : les langages de surface

Ces limites du langage ubiquitaire est une des raisons pour lesquelles Alberto Brandolini, une autre figure du DDD, affirme que c’est une “erreur commune de penser que tout le monde doit parler le même langage”. Ce n’est d’ailleurs pas la seule, le DDD reconnaissant la nature séquentielle du processus menant de la découverte du métier à la conception du code. Chaque étape a ses propres besoins, son contexte, ses interlocuteurs et le langage doit s’y adapter. De ce fait, ce n’est pas aux individus de s'adapter aux langages, mais aux langages de s’adapter aux individus et à leur environnement.

Bien sûr, les langages utilisés en dehors d’un Bounded Context présentent des similitudes avec celui employé pour modéliser un problème métier, notamment dans son objectif de fournir une communication claire et partagée. Si nous prenons l’exemple d’échanges au sein d’un conseil d’administration, il sera facile de remarquer que le langage reflète la terminologie propre à l’entreprise, précise et adaptée à des discussions. À ce titre, le langage “de surface” réduit les ambiguïtés et assure une compréhension commune - objectifs qu’il partage avec le langage ubiquitaire et qui pourraient amener à les confondre. Néanmoins, l’entreprise s’appuie premièrement sur des concepts qui sont généralement de plus haut niveau d’abstraction que ceux manipulés dans un Bounded Context. Pour reprendre l’exemple du langage d’un conseil d’administration, on y parle d’organisation, de budget ou d’opportunités stratégiques. Ces notions de haut niveau sont loin des concepts métiers manipulés dans un Bounded Context.

De plus, ce langage ne doit pas être confondu avec le langage ubiquitaire, car l’objectif de clarté est contrebalancé par le besoin d’être compris par une large population qui n’a pas la compétence - ni le temps - de maîtriser tous les détails de chaque domaine métier. En d’autres termes, un certain compromis entre ambiguïté et concision doit être accepté. Là où le langage ubiquitaire cherche constamment à accroître sa cohérence et à lever les ambiguïtés qui apparaissent à mesure que le projet se développe, les langages dit “de surface” devront s’adapter au fait qu’ils sont partagés par plusieurs communautés aux objectifs et intérêts différents voire opposés.

Enfin, un langage de surface correspond à des termes plus informels, liés aux usages quotidiens ou à des tendances passagères, souvent influencés par l’implémentation technique ou le contexte immédiat.

Pour conclure

Nous avons compris l’importance capitale du langage ubiquitaire dans le Domain-Driven Design parce qu’il forme avec le modèle mental deux faces d’une même pièce. Mais nous avons aussi vu que ce langage tire sa force du Bounded Context auquel il est attaché et qu’il est nécessaire de compléter ce langage “vernaculaire” de langages de surface qui permettent aux différentes parties prenantes d’une entreprise de s’accorder sur leur “lingua franca”.

Cette opposition ne reste néanmoins que la partie émergée de l’iceberg et l’avenir nous apprendra sûrement que d’autres langages cohabitent au sein d’une entreprise.

Charge au DDD de nous aider à les découvrir !

Resources

• DDD tales from ProductLand conference by Alberto Brandolini, Explore DDD 2024.
• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, 2003, Addison-Wesley Educational Publishers Inc.

Remerciements

Cet article a été écrit avec l’aide de la tribu Octo Domain Driven Design. Je remercie tout particulièrement Bruno Boucard pour les nombreuses idées qu’il m’a soufflées ! Merci aussi pour la relecture de Juliette Ferrer et Dorian Lamande.