- 02.21.17.75.78
- [email protected]
L'architecture en spaghetti est un terme péjoratif utilisé pour décrire une structure de code logicielle complexe et désorganisée, où les dépendances sont entrelacées de manière chaotique, rendant la maintenance et l'évolution du système extrêmement difficiles. Au début des années 2000, le code manquait de structure et ressemblait, au fil du temps, à un vrai plat de spaghettis, d'où son nom "architecture spaghetti". Ce mode de fonctionnement était très efficace pour le développement des premières fonctionnalités mais montrait très vite ses limites : plus le code s’étoffait, plus il était difficile de maintenir et de faire évoluer le logiciel.
Nous finissons notre parcours historique avec la démocratisation des pratiques qui suit l’avancement des technologies. Nous ne concevons plus des logiciels comme avant les années 2000. La démocratisation des bonnes pratiques, commencée depuis 2000, s’est professionnalisée à partir de 2015 avec, entre-autres, l’arrivée de l’architecture hexagonale et de la clean architecture.
Afin de pallier aux problèmes des architectures N-tiers, plusieurs alternatives ont émergé après les années 2000, dont l’architecture Hexagonale et la Clean architecture. Seulement, elles ne sont pas toujours bien comprises : pour expliquer l'une, certains utilisent parfois les termes de l'autre ; d’autres se basent sur des croyances plutôt que sur les publications d'origine. Et si nous comparions ces deux architectures pour lever le doute une fois pour toutes ?
Les problématiques rencontrées avec l’architecture spaghetti ont ainsi provoqué des réflexions sur la structure du code et son découpage de / des application(s) en couches. C'est dans ce contexte qu'émerge l'architecture en couches (aka "l’architecture lasagne"). Chacune de ces couches ayant une responsabilité précise : une couche gère les accès à la base de données, une autre gère la logique métier et une autre fait remonter les informations nécessaires aux rendus des vues utilisateurs.
Le problème de cette architecture est qu'elle relève d’une vision fonctionnelle calquée sur le modèle de données. En l'occurrence, dans le cas d’un modèle relationnel, limité par la rigidité de sa structure (notamment par l'interdépendance des tables), l'implémentation de la logique métier peut s'avérer douloureuse et difficilement testable en mélangeant le code d'intégration avec la logique métier. Ce qui aura pour conséquence de complexifier l'évolutivité du système.
L'exemple typique de cette complexité serait un changement sur le schéma de la base de données. Avec une vision métier dépendante de la structure d’une base de données relationnelle, toutes les évolutions fonctionnelles seront donc aussi complexes à gérer que les évolutions techniques. Un couplage était également présent avec les objets de persistance qui traversaient plusieurs couches.
L’arrivée des frameworks a alors facilité la vie des développeurs, mais les montées de version structurantes et le maintien des librairies pouvaient radicalement impacter le développement du métier.
Le concept des microservices a essayé de résoudre les inconvénients des architectures existantes par la division de l’application en petits périmètres moins complexes. Les micro-services peuvent être utiles à condition :
Sans respect de ces conditions, l'application risque de rencontrer les mêmes problèmes que les architectures précédentes voire pire car ces problématiques vont être distribuées dans tout le système !
Ces premières tentatives nous enseignent plusieurs éléments importants à retenir durant une phase de conception :
Deux alternatives majeures à l'architecture en spaghetti sont l'architecture hexagonale et la Clean Architecture. Ces approches visent à découpler les différentes parties d'une application, à isoler le cœur métier et à faciliter les tests et la maintenance.
L’architecture hexagonale a été imaginée par Alistair Cocburn en 2005. De par sa forme géométrique et ses côtés pour y placer des éléments, cette figure doit protéger la valeur en l'isolant des technologies qui l'entourent. L’hexagone pourrait intégrer une librairie, mais cela doit être justifié et rester exceptionnel.
Au milieu de l’hexagone se trouve votre métier (“Application”) qui communique grâce aux ports et adapters :
Les adapters, quant à eux, sont le monde extérieur par rapport au métier, c’est-à-dire la technologie :
Une belle illustration de cette architecture PORT ET ADAPTER est la prise électrique: elle donne de l'énergie, mais elle ne sait pas qui se branche à elle, de la même façon les ports n’ont pas conscience des adapters qui se branchent à eux. Le port peut avoir plusieurs adapters ou changer facilement si un jour la technologie change, sans modifier une seule ligne de code de l’hexagone.
L'implémentation des adapters commence avec les tests (par exemple, les tests unitaires côté gauche et une doublure côté droit). Ce choix d’architecture permet de repousser les choix technologiques. Le port de droite est représenté par une abstraction (interface), et l’adapter de droite est une classe qui va implémenter cette interface via de l'inversion de dépendances (le principe “D” de SOLID).
Concernant le port à gauche, c’est moins clair, cela peut être une interface comme le côté droit, soit une classe concrète qui peut être appelée par une autre classe adapter.
Le métier est représenté par une modélisation composée de structures simples. Dans ces modèles, nous avons les données (par exemple, l’objet Hôtel, Chambre ou Prix) et les comportements associés.
L’architecture hexagonale n’explique pas comment modéliser le métier. Afin de trouver ces éléments, il faut s'orienter vers les patterns tactiques du Domain Driven Design.
La clean architecture est représentée par des cercles concentriques. Elle a été imaginée par Robert C. Martin en 2012 (aka “uncle Bob”).
Ces cercles ont chacun des responsabilités:
En faisant un parallèle avec l’architecture hexagonale, l'hexagone représente des use cases et des entities. Les use-cases sont des ports de gauche et entities sont la partie “Application”. La gateway représente l’adapter de droite - la passerelle vers le monde technologique.
De même que tout à l’heure, si nous voulons nous prémunir des modifications technologiques, nous ne voulons pas mettre la technologie dans les deux premiers cercles les plus internes (entities et use-cases).
À la différence de l’architecture hexagonale, la mise en œuvre de la clean architecture demande toujours une interface à gauche (“Use case input port”). Le use case se conforme à cette interface et communique avec la gateway - donc l'extérieur - via son interface. Le retour des informations au port de gauche est représenté également par une interface (“use case output port”). Le contrôleur va fournir une implémentation de cette interface (par exemple qui pourrait transformer les données en JSON), ainsi, il ne retourne rien côté use-case, il alimente un presenter, le use-case n’a pas conscience de ce que fait le présenter, mais il l’appelle.
S’il faut retenir une chose concernant l'implémentation de la clean architecture: il est nécessaire d'avoir une interface en entrée et une interface en sortie.
Et si on fait le bilan, le design applicatif a-t-il besoin de l’architecture hexagonale ou de la clean architecture ? Parfois aucune des deux. Si vous travaillez sous le domaine qui n’est pas le cœur de votre applicatif, qui n’apporte pas d'éléments différenciants par rapport au concurrent, il est inutile de vous lancer dans la clean architecture. Si vous êtes dans le cœur de votre sous-domaine métier, mais que vous êtes dans l’audit ou des transactions financières, les architectures clean et hexagonales ne sont pas les choix les plus adaptés non plus.
En revanche, pour tout le reste, c’est tout à fait adapté et conseillé.
| Caractéristique | Architecture Hexagonale | Clean Architecture |
|---|---|---|
| Guidage | Moins guidé | Fortement guidé |
| Taille des ports | Pas de positionnement | 1 fichier (Screaming architecture) |
| Échange d’information | L'intérieur ne doit pas fuir. Retour classique puis le controller doit s’occuper du formatage /présentation des données | Plus de détail sur le rôle des couches externes. Utilisation d’un "présenter" permettant de découpler les responsabilités de présentation des données |
| Terminologie | Correspondance dans chacun des termes (par exemple, user-side adapter c’est un contrôleur et son implémentation, application, c’est entities) | - |
TAKE AWAY
Les 3 éléments importants à retenir :
Alors, vous vous dîtes : “Cet article est très intéressant, mais nous n’avons toujours pas la réponse : Hexagonal ou Clean architecture ?!”
Et voilà la réponse : “Entre hexagonal et clean … C’est la clean archigonale !”
Nous pouvons prendre le meilleur de deux mondes : par exemple, le terme de “use case”, la taille de ports avec la scream architecture, l’adapter ou le repository (terme DDD), présence d’une interface sur le use case si vous voulez tester le contrôleur, etc. Bref, vous pouvez faire un mix avec l’aide du DDD au milieu qui va aider à désigner le modèle.
Le défi du pont en spaghetti est une activité ludique et éducative qui consiste à construire une structure autoportante à partir de spaghettis, de ficelle, de ruban adhésif et d'un marshmallow. Ce défi met en évidence des modèles comportementaux intéressants, que ce soit dans un cadre compétitif ou collaboratif.
L'idée de mettre le marshmallow challenge à l'échelle est venue lors d'une présentation dans une école. Le jeu consiste à former des équipes (3 à 6 personnes) qui doivent construire la plus haute tour possible avec 20 spaghettis, 1 m de ficelle, 1 m de scotch et un marshmallow à mettre au sommet. Hervé s’est dit qu’il serait amusant de proposer une version à l’échelle, car le Marshmallow Challenge nous a semblé adapté pour animer des ateliers pour 80 étudiants.
Dans le cadre d'une expérience avec des débutants en agilité, aucune équipe n’a pensé son architecture sous l’angle de l’interconnexion. Les équipes ayant essayé de s’interconnecter ont dû réfléchir au meilleur endroit pour modifier la structure. J’aime bien demander si les équipes étaient sereines à la livraison. Cette question me permet de mettre en perspective la construction itérative, la prise de risque et la confiance dans le processus.
Nous avions 4 équipes qui se sont vites rassemblées. Le groupe était mené par 1 ou 2 personnes qui faisaient les propositions d’architecture. La réunion initiale a principalement poussé le fait de s’interconnecter rapidement et surtout construire rapidement. On a constaté la présence de 18 participants dont 4-6 actifs et 12-14 en retrait. Et oui, sans réunion sur comment s’organiser ? Construire un pont incassable avec des spaghettis !
Les tours co-construites et intégrées directement étaient plus petites que les tours créées dans leur coin. L’équipe a tout de même réussi le challenge puisqu’à la fin nous avions une structure qui a tenu voir que l’on a pu manipuler (avec grande précaution tout de même). Le bonus de 50 points a été totalement oublié au profit du collectif. Je pense que l’ambiance globale a généré une appartenance au groupe complet. Ceci dit, il pourrait être intéressant d’étudier cela sous l’angle du dictat du collectif.
Des concours de construction de ponts en spaghetti existent, où les participants doivent créer un pont d'une longueur spécifiée, capable de supporter un poids maximal. Un exemple est un concours où le pont doit faire un mètre de long, 8 cm de large, et être construit avec 500g de spaghetti et 24 tubes de colle en 3 heures. Le pont doit être le plus solide possible.
L'analogie de l'architecture en spaghetti peut également être appliquée à des infrastructures complexes dans le monde réel, comme les échangeurs autoroutiers.
La construction de l’impressionnant échangeur de Huangjuewan, en périphérie de la municipalité de Chongqing (Chine), s’est achevée. Mais les automobilistes semblent perdus face à cette « route à choix multiples ». Et cette nouvelle « route à choix multiples » affole déjà les malheureux automobilistes chinois…
Cinq niveaux de circulation différents. Vu du ciel, cet échangeur semble avoir la forme d’un plat de spaghetti, avec des bretelles sur cinq niveaux qui s’entremêlent. Huit années ont été nécessaires pour construire cet édifice près de Chongqing,ville réputée comme une cité laboratoire au sud-est du pays.
Cinq voies de circulation se superposent, dont la plus haute culmine à 37 mètres. Quinze bretelles ont dû être construites pour permettre aux véhicules de passer d’un niveau à l’autre, dans huit directions, précise le site internet de la municipalité.
La modernisation de la R.D. 939 est une bonne nouvelle pour tous les usagers. 3,5 nouveaux kilomètres viennent d’être mis en service. Ils concernent la section entre Haute-Avesnes et Aubigny-en-Artois, commune également équipée d’un nouveau giratoire. Réalisée en un temps record, cette nouvelle portion à 2 x 2 voies illustre l’engagement du département pour la modernisation de cet axe.
Retour en 2015 : le Département engage un vaste chantier de restructuration de la R.D. 939 entre Arras et Saint-Pol-sur-Ternoise afin d’améliorer la sécurité routière, de fluidifier le trafic et de contribuer au développement économique des territoires irrigués. Sur cette partie, la section Etrun-Aubigny est la première à être concernée par les travaux. Elle représente 7 km, totalement réaménagés en 2 x 2 voies avec la réalisation de carrefours giratoires, pour un investissement global de 23 millions d’euros. Deux ans seulement ont été nécessaires pour atteindre l’objectif.
La chaussée existante a été doublée et deux nouveaux giratoires ont été aménagés. Le premier à Haute-Avesnes (carrefour avec la RD62) et le second à Aubigny-en-Artois (carrefour avec la RD74). Ils viennent compléter celui qui existait déjà à Etrun. Les travaux pour la section de Haute-Avesnes à Aubigny-en-Artois ont commencé au début du mois de mai. En 7 mois seulement, les 3,5 km de tronçon ont été achevés, avec plusieurs mois d’avance sur le calendrier initial. Les déviations actuellement en place pour rejoindre Hermaville et Aubigny-en-Artois par la R.D.74 sont donc levées.
Mise aux normes avec création de bandes d’arrêt d’urgence, rectification du profil en long pour améliorer les conditions de visibilité, suppression des accès directs depuis les chemins agricoles, suppression du terre-plein-central végétal et remplacement de celui-ci par une glissière béton : la nouvelle route comporte tous les atouts techniques d’une voie express moderne et sécurisante.
tags: #structure #en #spaghetti #architecture
Vrac zéro déchet et Primeurs de saison au plus proche de chez vous à Thorigné-Fouillard près de rennes en Ille et Vilaine 32
© 2021 - Du bocal à l'assiette - Tous droits réservés / création web : 6cyic
