Partie II. Transformation technique, tactique et organisationnelle de l'équipe Transformation axée sur le domaine
Décomposer un système existant avec la transformation axée sur le domaine, c'est un gros boulot. Comme pour une personne avant une grosse opération, il faut s'assurer que le patient est en aussi bonne santé que possible. Comment faire ça, c'est le sujet de cette deuxième partie du livre.
La plupart des systèmes hérités que nous voyons sont en mauvais état général : non seulement ils sont constitués d'une ou plusieurs grosses boules de boue, mais ils souffrent également des problèmes suivants :
-
Ils sont devenus rigides et peu flexibles, difficiles à modifier, et les changements sont très sujets aux erreurs en raison de leur structure complexe et difficile à comprendre.
-
Dans l'ensemble, par rapport aux systèmes dotés d'une bonne architecture, ils comportent de nombreuses erreurs non détectées, voire connues, une couverture de test insuffisante conduisant aux premières, et de nombreuses failles de sécurité dues à des bibliothèques obsolètes.
-
Ils sont difficiles à construire et à déployer.
-
Ils manquent de qualité, même au niveau des simples mesures de code, comme la longueur des classes et des méthodes, les cycles entre les classes, le nombre de paramètres, etc.
Si un système existant est dans un état aussi critique, on ne peut pas se lancer tout de suite dans la transformation stratégique axée sur le domaine (partie III). On doit d'abord améliorer l'état général ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access