Eric Evans (le papa du "Domain Driven Desing") faisait ce matin une présentation sur les stratégie de modélisation du domaine métier, et en particulier sur la reprise d'application existantes mal strucutrées.
- Option 1 : On jette et on reconstruit un code propre. Il n'a jamais vu cela fonctionner, c'est extrèmement couteux, et on a au final un code qui marche a peine aussi bien que le précédent en ayant couté le double et en étant pas plus simple à maintenir
- Option 2 : refactoring intensif. Intéressant car il ne gèle pas les évolutions de l'existant, mais potentiellement très imparfait, et surtout pas visible en terme de retour sur investissement (le fameux "qui paye pour ça ?".
- Option 3 : le "hack" du code existant pour venir piocher le "core model". Pas vraiment très satisfaisant
- Option 4 : dédier un modèle à chaque contexte, et créer des couches de médiation. Ca rejoint un peu la problématique SOA (transformation des données XML d'un système à l'autre).
D'après lui c'est LA solution fiable, à condition d'accepter deux points :
- Une application ne peut pas être totalement propre
- Il n'y a pas un modèle, mais N modèles associés à N contextes
Je reste convaincu par le refactoring, mais il faut bien reconnaître qu'il a ses limites sur du code vraiment très volumineux ou totalement monolithique.
1 commentaires:
j'aurais tendance a opter pour l'option 4 , moi aussi
en fait ce qui me reste des différentes expériences de refactoring sur de très gros applicatifs (merdique cela dit), c'est la limite à modéliser des systèmes complexe au delà d'un certain nombre de classes(ou de fonctionnalités)
En fait mon sentiment global et que les modèles objets ne peuvent couvrir qu'un domaine fonctionnel assez limité après on a tendance a faire trop de compromis qui ne donne plus satisfaction.
Enregistrer un commentaire