Démystifier la Clean Architecture : Fondamentaux et Avantages
Imaginez construire une maison avec un plan incohérent, où les murs, le toit et les fondations se mélangent dans un joyeux chaos… Et bien c’est justement ce à quoi peut ressembler le monde du développement ! On ne va pas se mentir, ça arrive même (bien trop) souvent. On a probablement toutes et tous été confrontés au plat de spaghettis, un code où tout est mélangé et difficilement maintenable. La Clean Architecture va être le maitre d’oeuvre qui accompagne la construction de la maison, et va apporter un cadre qui apporte de l’ordre dans la complexité croissante des applications modernes.
Qu’est-ce que la Clean Architecture ?
La Clean Architecture n’est pas simplement un terme à la mode. Résultat des travaux de Robert C. Martin (une publication en 2012 puis un livre en 2017 toujours disponible), c’est un concept de plus en plus incontournable dans le développement moderne qui propose une approche structurée pour concevoir des applications robustes, plus facilement maintenables, et scalables.
Définissons d’abord les bases.
Définition
La Clean Architecture vise à séparer clairement les préoccupations, avec d’un côté les aspects métiers, et de l’autre les aspects techniques. Elle vise également à garder un contrôle essentiel des dépendances, en évitant d’être fortement lié ou couplé à celles-ci.
Ce sont donc les deux principes fondamentaux :
1- Séparation des préoccupations
Avec la Clean Architecture, imaginez chaque élément de votre application ayant un rôle clair et distinct. La logique métier ne se mélange pas avec les détails techniques. L’application est divisée en couches, chacune sa responsabilité.
2- Indépendance des frameworks et des outils
Ici, la flexibilité est la clé. Votre application doit être agile et capable de s’adapter aux changements sans compromettre sa stabilité. Une faille de sécurité importante dans une dépendance ? Contrainte RGPD sur une autre ? Peu importe, l’adaptation du code, le remplacement vers une autre dépendance, doit se faire sans douleur.
Les couches de la Clean Architecture
Dans la partie définition, on a abordé la décomposition en plusieurs couches distinctes, chacune avec une responsabilité et un rôle spécifique, en suivant le principe de l’isolation.
Plongeons dans les détails
La Couche Entités
Les entités forment le cœur de la modélisation du domaine, du métier. Ce sont les blocs de construction de votre application, les gardiens de la logique métier, sans se soucier des détails technique, de la persistance des données… Etc.
La Couche Cas d’Utilisation (Use Cases)
Les cas d’utilisation sont comme les chefs d’orchestre de votre application. Ils dirigent la logique métier et assurent que tout se déroule harmonieusement avec une coordination entre les différentes parties de l’application. Ils décrivent avec clarté les scénarios de la logique métier. J’aime préciser que l’oeil du Product Owner peut être intéressant dans cette couche !
La Couche Interfaces Utilisateur (Interfaces Adapters)
Dans cette couche, nous nous occupons des interactions avec le monde extérieur. Les interfaces utilisateur et les adaptateurs gèrent les entrées et les sorties, comme une passerelle entre le l’application et les dépendances externes.
La Couche Infrastructure
Enfin, la couche des infrastructure est l’antre de la technique. Elle est responsable de l’interaction avec les bases de données, les frameworks, et tout ce qui concerne les aspects techniques.
Chaque couche est isolée, est indépendante. Pour les faire communiquer entre elles, on va utiliser ce qu’on appelle l’injection de dépendance.
Pourquoi opter pour la Clean Architecture ?
Maintenant que nous avons vu les fondamentaux et comprenons les bases, voyons les avantages concrets des principes de la Clean Architecture.
Meilleure maintenabilité & évolutivité
Notre maitre d’oeuvre a rempli sa mission, la maison est bien conçue et chaque pièce d’adapte à un seul besoin. Si je souhaite ajouter une pièce, ou changer une fenêtre, c’est tout de suite plus simple ! La Clean Architecture apporte cette flexibilité, et permet à l’application de s’adapter et grandir sans difficulté. A l’inverse d’un code spaghetti, où quand on tire d’un côté, ça crash de l’autre.
Meilleure testabilité
C’est assez logiquement qu’avec le principe de l’isolation, de séparation des préoccupations,, où chaque couche a sa propre responsabilité, que la structure du code facilite la mise en place de tests unitaires. Des éléments simples amènent des tests simples, des tests simples signifient un code plus robuste.
Indépendance technique
Toujours dans notre maison, pensez à pouvoir changer les meubles sans affecter la structure de base. C’est exactement un des principes fondamentaux de la Clean Architecture, l’indépendance de la couche technique. Si pour changer la table, je dois changer le carrelage, deux murs et trois fenêtres, c’est tout de suite un autre projet !
Compréhension plus claire de la code base
En suivant les principes de séparations des préoccupations au niveau de la structure du code, on retrouve côté développeur un parcours clair à l’intérieur et entre chaque couche, ce qui va faciliter la compréhension des différentes parties de l’application.
Des inconvénients ?
Bien évidemment et comme souvent dans le monde du développement, tout n’est pas noir ou blanc. Si on a des avantages, on a des inconvénients : Plus de complexité dans le développement, une courbe d’apprentissage un peu plus élevée, il peut être intéressant de franchir les quelques marches en suivant une formation. On peut également ajouter une taille du code source plus volumineuse, voire ce qu’on peut considérer comme du surdéveloppement, et une complexité lors de la configuration initiale.
Pour terminer
La Clean Architecture n’est pas seulement une méthode de développement, c’est une philosophie qui change la manière dont nous concevons nos application. En adoptant ses principes, on s’assure de développer des applications robustes, évolutives et plus faciles à maintenir. Et forcément, c’est aussi une amélioration de l’expérience développeur, que nous aborderons dans un article à part entière.
Mais ce n’est pas une solution magique non plus ! C’est une architecture de développement, comme il y en a d’autres, et comme il y en aura d’autres demain. C’est à vous de déterminer si pour votre projet, votre contexte, la Clean Architecture est un bon choix. Durant une de mes expériences, nous avons développé un POC, dans le but de valider un marché et des spécifications techniques Web 3. Nous avancions sans réelles spécifications fonctionnelles, chaque jour apportait, supprimait, modifiait une feature : Ca aurait été bien trop couteux de s’assurer d’avoir une structure clean, pour un code que nous avions déjà prévu de “jeter”.
Mais quoi qu’il en soit, avec la montée en puissance des IA génératives ou des applications Low Code / No Code (et des deux en même temps demain ?) la part de marché des applications développées avec un outil va encore croitre et prendre sa place, c’est ma conviction . Toute application qui ne rentrera pas dans cette catégorie, sera forcément plus complexe, exigera de répondre à des défis que le Low Code / No Code ou l’IA ne pourra résoudre. Ca demandera donc forcément une structure solide, robuste, scalable, maintenable, tout ce que propose aujourd’hui la Clean Architecture, et pourquoi pas une nouvelle méthode ou de nouveaux principes demain !
Un article de Nicolas Lapointe.
Cet article est une introduction à la Clean Architecture, et fait partie d’une série dédiée sur ce sujet. Rendez-vous sur les prochains !
Articles sur la Clean Architecture :
