Le découpage d'une application n'est pas une décision évidente ou anodine : il conditionne à la fois la lisibilité générale, la testabilité et enfin sa capacité à évoluer dans le temps.
Lorsqu'un composant concentre trop de responsabilités, il finit inévitablement par devenir un point de fragilité dans une architecture : la compréhension se complique, les dépendances se multiplient et les tests deviennent laborieux et difficilement exhaustifs.
Cette tendance est courante lorsqu'on privilégie un découpage trop vertical des responsabilités, conduisant à faire reposer l'ensemble du code sur un petit nombre de composants clés :
Dans cette situation, les fonctionnalités viennent progressivement s'empiler sur un socle unique, cette approche, simpliste dans un premier temps, présente un certain nombre de problématiques :
- La scalabilité est limitée car tout repose sur un seul point central
- La complexité augmente car chaque nouvelle fonctionnalité vient enrichir un bloc principal
- La fiabilité diminue car le moindre bug peut avoir des répercussions globales
- La testabilité se dégrade progressivement, l'isolement et l'identification des comportements devenant presque impossibles
Une alternative à ce découpage consiste à considérer et à répartir les responsabilités de manière plus horizontale. Plutôt qu’un cœur unique, le code se compose désormais d’un ensemble de composants, chacun dédié à une responsabilité claire et un périmètre fonctionnel limité :
Ce choix entraine plusieurs choses positives :
- La complexité se distribue et devient plus gérable
- Le risque d'erreurs diminue également car chaque composant reste limité en taille et en portée
- Les composants deviennent plus faciles à tester car moins interdépendants et plus isolés les uns des autres
- Les composants deviennent réutilisables, car plus générique, ce qui favorise la consistance globale du système
Le passage d’un découpage vertical à un découpage horizontal n’est pas seulement une réorganisation technique, c’est également un changement de perspective : on ne conçoit plus le système comme un bloc unique qui accumule tout mais comme une série de briques coordonnées, chacune limitée et claire dans son rôle.
Avec cette approche, la simplicité apparente d’un composant unique laisse place à une architecture plus robuste, plus souple et surtout plus durable.
Ce découpage, bien que positif sur de nombreux points, introduit cependant un phénomène de scattering : une dispersion du flux de lecture. Là où un unique fichier central permettait autrefois de suivre d’un seul regard la totalité d’une fonctionnalité, il est désormais nécessaire de naviguer sur un ensemble de composants pour en comprendre le cheminement.
Ce scattering peut provoquer une surcharge cognitive mais il reste un compromis acceptable : la lisibilité d’ensemble et la fiabilité obtenues compensent largement ce coût ponctuel, surtout quand des enjeux d’évolutivité et de maintenabilité sont importants.
De plus, la lisibilité supposée d'un composant unique se dégraderait inévitablement à mesure qu’il s’alourdirait avec le temps et gagnerait en richesse fonctionnelle.
En résumé : le découpage vertical peut suffire à court terme ou sur des périmètres restreints, mais un découpage horizontal, plus exigeant à mettre en place, est un investissement intéressant sur le long terme en termes d’évolutivité et de robustesse.
« Complexity grows exponentially if you try to do everything in one place. Break it into smaller, cohesive units »
— Martin Fowler