Domain Driven Design, l’opportunité de maturité pour l’entreprise Agile

Nous avons tous une fois où nous avions regardé le film de l’un de nos livres best sellers favoris, et que nous trouvions le film complètement à coté du livre. Les personnages ne correspondent pas du tout à ceux du film, les scènes les voix des acteurs etc. Un échec total!

Mais quand on y pense un peu. Le film ne correspondait simplement pas à notre version. Nous aurions aimé que le film corresponde à ce que nous avions imaginé. En fait, ce n’est pas le livre qui est fantastique, ni le film qui est pourri.. c’est plus l’histoire que nous avions représenté à l’intérieur de notre esprit, les images, les sons, les scènes et les sentiments que nous avions ressenti en modélisant ce qui est raconté dans le livre.

Plusieurs perspectives, et non une seule réalité

Et ce n’est pas différent au travail. Comme membre d’une équipe Agile, comme développeur, nous concevons des modèles qui reflètent notre compréhension du problème que nous essayons de résoudre.

Par exemple, quand nous travaillons dans un contexte ou le projet touche à plusieurs unités, processus, services etc. Et qu’il nous arrive d’interagir avec d’autres équipes, départements, unités ou autre, il est fréquent que ces intervenants modélisent les choses différemment des nôtres. Ils conçoivent les choses en se basant sur plusieurs éléments, comme leur expérience, leur domaine de responsabilité, leur domaine d’affaire. Leur réalité est différente de la notre. Ces différentes perspectives se reflètent généralement sur le langage utilisé. Nous nous rappelons tous d’une discussion sans fin sur un terme ou un autre entre plusieurs intervenants lors une réunion d’alignement. Des fois la situation s’empire quand nous commençons à avoir des préjugés parce qu’une autre équipe ou un intervenant dans le projet ne conçoit pas les choses de la même façon.

Pour nous donner raison en partie, en effet, l’alignement sur les termes utilisés pour représenter la réalité du domaine de notre entreprise est un exercice extrêmement difficile. Dans ce cas, notre premier réflexe est de travailler à unifier la définition des concepts à travers l’ensemble des unités intervenant sur un produit. Certains projets tombent dans le piège de créer un modèle complètement inclusif. Un modèle dont l’objectif est d’avoir l’entièreté de l’organisation qui s’accorde sur des concepts avec des noms qui ont un seul sens global.

Effectuer un effort de modélisation entièrement inclusive est un piège. Pourquoi?

Premièrement, il est presque impossible d’établir un accord  entre plusieurs intervenants qu’un concept aie un sens global, unique et distinct. Plusieurs organisations sont trop larges et complexes qu’il est impossible d’avoir toutes les parties-prenantes ensemble dans une salle. Même si vous travaillez dans une petite compagnie avec quelques parties prenantes, établir une définition stable d’un seul concept globalement reste extrêmement  difficile.

Comment ce problème est résolu en Agilité?

Dans le mode de l’agilité, ce problème est résolu par les techniques présentés dans l’approche du Domain Driven Design [Eric Evans]  ou Développement Piloté par le Domaine,  d’une façon extrêmement élégante que je voudrais introduire à ceux de vous qui n’en sont pas au courant.

Avec le DDD, au lieu de chercher à aligner les gens, et changer leurs perspectives en renommant des concepts en concepts globaux. Nous prenons l’approche inverse, celle de simplement visualiser les différences en séparant les domaines et en délimitant les différences entre elles explicitement. Nous ne faisons que représenter la vraie nature des choses, nous représentons la réalité au lieu d’en inventer un autre modèle.

En plaçant le modèle de chaque domaine dans un contexte délimité clairement, il devient facile de donner un sens spécifique aux termes et phrases représentant ce domaine, et le modèle reflètera exactement le langage spécifique du domaine.

Comment le Domain Driven Design peut nous aider sur le plan stratégique?

Sur le plan stratégique, le DDD offre une approche permettant la conceptualisation et l’alignement entre les experts du domaine et les développeurs. Cette approche contient des notions entre autres de  « langage omniprésent (Ubiquitous Language)» , de  « cartes de contexte (Context Maps) », ou encore via des techniques comme celle du « Event Storming » qui est une technique de visualisation qui se rapproche beaucoup de celle du « user story mapping ».

Cette approche permet de bien adresser la complexité présente dans la réalité de toute organisation. Elle permet aux développeurs de  représenter les concepts du langage métier dans le code. La séparation des concepts en plusieurs contextes délimités clairement permet de respecter le principe de responsabilité unique (Single Responsibility Principle). Elle diminue aussi le couplage entre les services formant le produit.

En terme d’efficacité du projet, elle garantit un cheminement et un alignement entre développeurs, experts de métiers et parties prenantes. C’est une approche qui peut être mise en échelle puisqu’elle distribue les concepts dans des contextes clairement délimités.

Sur le plan humain, elle donne aux intervenants, quelque soit leur métier, un outil qui leur permet d’être plus confortables. Elle permet à chaque membre d’équipe, à chaque unité d’affaire de représenter les choses selon sa compréhension. Les experts de domaine ne se trouvent pas contrains d’inventer des noms pour leurs concepts d’affaire.

Pour nous, mes chers développeurs, Rendre notre code adaptable aux changements fait partie de notre quête de changement. Au fur et à mesure que nous grandissons, en tant qu’êtres humains, et que nous acquérons de nouvelles compétences et devenons plus matures, nous acceptons que d’autres équipes et parties prenantes dans l’entreprise ont le droit de voir, concevoir et implémenter les choses différemment, quand leur choix ne nous impact pas grandement. Nous nous concentrons sur les opportunités que ces situations de collaborations nous offrent, et nous essayons de trouver comment nous pouvons être de meilleurs développeurs, et comment améliorer notre design afin d’être mieux adapté à la nouvelle situation que nous vivons.

Comment le Domain Driven Design peut nous aider sur le niveau tactique?

Sur le plan tactique, l’approche du DDD nous offre des notions concrètes que l’on peut utiliser lors du développement.

Un premier concept est celui des agrégats, entités et objets valeur qui nous permettent de représenter correctement et convenablement le modèle du domaine, en s’assurant de renforcer les règles d’affaires en termes de transactions et de consistance directement dans le code, et en offrant un découplage et une résilience qui permet d’agiliser notre code.

Un deuxième concept est celui des évènements de domaine, qui est une excellente façon d’assurer l’autonomie et l’inter opérabilité des services.

Un troisième concept extrêmement intéressant est celui du « niveau d’anticorruption » qui, comme son nom l’indique, nous permet de protéger notre modèle contre le bruit, les changements, les différences de conceptualisation qui sont faites dans les domaines en amont de notre domaine.

Je reviendrai avec beaucoup plus en détail sur l’ensemble des notions stratégiques et tactiques que je viens de vous introduire ici dans de prochains posts. Restez branchés!

Mes chers développeurs, en apprenant ces nouveaux concepts de développement Agile, nous avons tous les outils nécessaires pour faire le meilleur travail qui soit. Nous avons toutes les ressources disponibles pour nous pour être ceux que nous sommes vraiment, des gens créatifs, innovants et bâtisseurs.