L'analyse stratégique au secours du legacy

L'utilisation des concepts stratégiques du Domain Driven Design est très puissante pour aborder sereinement la mise sous contrôle d'un logiciel legacy devenu incontrolable. Construire une cartographie sommaire des domaines et sous-domaines, de leur relations et des contextes existants apporte beaucoup d'information.

Pour le legacy typique, il est probable que la carte obtenue soit un beau bazar, avec des chevauchements de contextes et domaines, et un écheveau inextricable de relations.

C'est le premier intérêt de l'approche. Instantanément, faire l'effort d'identifier les domaines, leur importance stratégique, leurs relations, les différents contextes pas vraiment délimités, au sein d'une représentation visuelle simple permet de comprendre pourquoi travailler sur l'existant est devenu si difficile.

Quand on est confronté au quotidien à un logiciel qui résiste au changement, il n'est pas toujours évident de comprendre pourquoi. On peut blâmer les choix techniques. On peut identifier la mauvaise application des bonnes pratiques de code, les outils, ou encore le manque d'expérience de l'équipe. Tout cela peut être vrai, à un niveau micro. A un niveau macro, la raison principale c'est l'absence de conception, la non connaissance des domaines et contextes que l'on manipule qui en découle, et, finalement, le désalignement entre le métier et la solution.

Pouvoir visualiser très concrétement pourquoi ce que l'on manipule est si résistant, c'est un soulagement. Une première étape nécessaire pour améliorer les choses. C'est rassurant.

L'exercice permet de se doter d'outils pour avancer. La classification des domaines, la visualisation des relations entre eux et de l'existant donnent des éléments pour identifier et prioriser les zones les plus critiques sur lesquelles travailler. Cela permet d'obtenir des informations que l'on aurait pas autrement.

Finalement, dessiner une carte idéale de ce que devrait être la solution est aussi libérateur. Cela donne une perspective positive. Cela trace le chemin pour avancer. Au moins maintenant, on a peut être pas réparer le logiciel, mais au moins, on ressent pourquoi il est tel qu'il est, on sait quel objectif viser pour faire mieux, et on sait quels sujets doivent être gérés en premier.

Cela vaut le coup de passer quelques heures de réflexion non ?