L'architecture en tranches verticales est une méthode de conception de logiciels qui organise les fonctionnalités en tranches ou "slices" verticales couvrant toutes les couches de l'application, de l'interface utilisateur à la base de données. Chaque tranche est conçue pour être autonome et gérer une fonctionnalité spécifique, promouvant ainsi un développement modulaire. Mais est-ce une si bonne idée ?
Sur le papier c'est une approche qui semble intéressante. Et en même temps elle semble remettre en cause des décennies de génie logiciel ayant abouti à DRY, SOLID et des patterns comme MVC, MVMM, etc. Qu'en est-il vraiment ?
Avantages de l'Architecture en Tranches Verticales
Soyons bons joueurs et commençons par les avantages de cette stratégie.
- Cohésion et Découplage : Chaque tranche est indépendante des autres, ce qui favorise le découplage et une meilleure cohésion au sein de la tranche. Cela peut simplifier les mises à jour, les tests, et le déploiement de fonctionnalités spécifiques.
- Développement Parallèle : Comme les tranches sont indépendantes, plusieurs équipes peuvent travailler simultanément sur différentes fonctionnalités sans interférence, accélérant le développement.
- Facilité de Maintenance et d'Évolutivité : Il est plus facile de comprendre, maintenir et étendre une tranche dédiée à une seule fonctionnalité plutôt qu'une grande base de code interdépendante (l'une des stratégies consistant à placer tout le code d'une feature dans un seul fichier source regroupant ainsi toutes les couches nécessaires à l'accomplissement de la feature).
Inconvénients et Critiques
Les louanges c'est bien mais quelles que soient les modes l'important est de conserver un esprit critique. Voyons les reproches qu'on peut faire à cette architecture :
- Redondance Potentielle : Il peut y avoir une certaine redondance dans le code entre les tranches, particulièrement au niveau des couches d'infrastructure ou de persistance. Adieu DRY !
- Complexité de Gestion : Gérer plusieurs tranches verticales peut devenir complexe, surtout si les fonctionnalités se chevauchent ou interagissent fréquemment. On va multiplier les astuces et les librairies tierces pour s'en sortir ce qui va encore plus complexifier le code et le rendre finalement inmaintenable.
- Performance : Il peut y avoir des défis en termes de performance, notamment si les tranches doivent interagir ou si l'application doit gérer des transactions complexes à travers plusieurs tranches. Ce n'est tout simplement pas penser pour cela, ce qui est dommage puisque cette architecture s'adresse plutôt à des gros projets complexes où justement on va rencontrer plus facilement des interactions entre tranches, du transactionnel etc.
Réception dans la Communauté du Génie Logiciel
Qu'en pense le métier ?
Des experts reconnus en génie logiciel expriment des avis divergents sur l'architecture en tranches verticales. Ses partisans affirment que cette méthode s'harmonise davantage avec les principes de l'architecture microservices, en promouvant l'autonomie et la modularité. En revanche, ses détracteurs soutiennent qu'elle peut générer une complexité superflue, particulièrement dans les projets de petite ou moyenne envergure où une architecture monolithique serait plus simple et également performante.
Débats Autour de l'Architecture
Des débats émergent quant à cette méthode d'architecture d'application. Les discussions portent fréquemment sur la préférence entre l'architecture en tranches verticales et d'autres méthodes telles que les architectures monolithiques ou à couches. Ce choix est généralement influencé par des facteurs tels que la taille de l'équipe, la nature du projet, la complexité des fonctionnalités et les buts de l'entreprise.
Protagonistes et Médias
- Auteurs : Les auteurs tels que Martin Fowler et Robert C. Martin ont discuté des concepts qui pourraient être vus comme des précurseurs ou des analogues à la vertical slice architecture, bien que leur travail ait souvent été plus centré sur des principes de conception et moins sur des prescriptions architecturales spécifiques.
- Publications et présentations dans des conférences : Les discussions autour de l'architecture en tranches verticales ont souvent lieu dans des contextes de conférences professionnelles sur l'Agile, le développement de logiciels et la conception de systèmes. Des plateformes comme InfoQ, Medium, et d'autres blogs spécialisés en développement logiciel ont aussi contribué à la diffusion de ces idées.
On retrouve ici l'esprit de clan, le regroupement autour des quelques médias ayant un parti pris. L'informatique n'est pas si différente de la vie en général où les opinions se forment pour les uns autour de BFM ou pour d'autres CNEWS. Nulle intention ici de vouloir départager ces clans, Dot.Blog ne fait pas de politique, mais bien d'insister sur le danger du cloisonnement en matière d'info, l'infox n'est jamais loin. Faites avec votre esprit comme avec votre maison : aérez souvent pour assainir l'air, ne pas vivre en vase clos, et ouvrir votre pensée à d'autres horizons. Les discours au moule qui paraissent trop beaux pour être vrais, sont souvent trop beaux pour être vrais...
Origines et Évolution
La vertical slice architecture, comme concept appliqué dans le développement logiciel, n'a pas une origine clairement définie. Cependant, elle semble avoir évolué comme une synthèse de plusieurs pratiques et tendances en développement logiciel, notamment l'adoption plus large de l'Agile et des microservices. Cette façon de structurer une architecture n'est donc pas le fruit d'une réflexion d'un ou plusieurs auteurs réputés comme le fut le Gang Of Four, mais une succession d'articles et de discussions au sein d'une communauté, celle de l'Agile, dont on connait les visions parfois outrancières et l'apparente déconnexion de la réalité. Beaucoup de mots, nouveaux de préférence, pour parler des problèmes éternels du développement en promettant à chaque fois la productivité de 10 hommes (ou femmes) avec un seul dev... (les patrons - généralement incompétents en informatique - aiment ce mot "productivité" et achètent très facilement ces discours, mordant à l'hameçon comme un bon ver bien gras attire le poisson affamé pour la joie du pêcheur !).
Développement historique
- Origines dans le développement Agile et Scrum : L'idée de développer des fonctionnalités en tranches verticales peut être reliée aux pratiques du développement Agile et de Scrum, qui préconisent de diviser le travail en petits bouts fonctionnels qui peuvent être développés, testés et révisés de manière itérative et incrémentale. Ces méthodologies ont commencé à gagner en popularité au début des années 2000. Avec le recul elles ont largement prouvé leurs limites mais il reste des niches où elles sont devenues des sortes de sectes avec leurs adorateurs. L'informatique est supposée être rationnelle, mais les informaticiens qui la pratiquent ne le sont pas forcément !
- Influence des microservices : Le concept de microservices, qui a commencé à émerger comme une approche distincte dans les années 2010, partage certaines similitudes avec la vertical slice architecture en termes de découpage d'une application en parties plus petites et autonomes. Bien que les microservices soient généralement considérés comme des entités plus autonomes et distribuées, l'idée de travailler sur des segments verticaux peut être vue comme une étape préalable ou complémentaire à l'adoption de microservices. On notera que ces parallèles entre les méthodes permettent par glissements de sens successifs de trouver des rapprochements là où il existe des gouffres. Méfiance donc. Les microservices c'est très bien, mais ils n'obligent en rien à mettre en place une architecture de type vertical slice architecture.
Conclusion
Une fumisterie de plus ? La vertical slice architecture n'est pas nécessairement une anti-pattern; elle peut être extrêmement utile dans certains contextes, notamment dans des environnements où l'évolutivité, la modularité et l'autonomie des équipes de développement sont prioritaires. Mais c'est loin d'être une panacée applicable partout et tout le temps. Elle pose des problèmes variés, elle complexifie souvent inutilement les applications qui deviennent difficilement maintenable dans le temps. Ainsi, comme pour toute décision architecturale, elle comporte des compromis et doit être évaluée par rapport aux besoins spécifiques du projet et aux capacités de l'équipe. Se jeter sur cette approche comme étant la meilleure du monde serait tout aussi stupide que de l'ignorer au prétexte qu'elle présente des défauts. Aucune architecture n'est valide à 100% pour tous les cas de figure. Mais certaines sont moins pertinentes que d'autres malgré tout.. Qu'en pensez-vous ?
Stay Tuned!
Le Guide Complet de.NET MAUI ! Lien direct Amazon : https://amzn.eu/d/95wBULD
Près de 500 pages dédiées à l'univers .NET MAUI !
Existe aussi en version Kindle à prix réduit !