Par Jonathan P.

Introduction

Dans cet article, je ne vais pas rentrer en détail sur ce qu’est la Clean Architecture, cependant vous pourrez retrouver des liens vers plus de documentation. Je vais plutôt aborder une question que je me suis posée après un projet dont la dernière étape à laquelle j’ai participé était un refactor de la structure vers une Clean Architecture.

I. Qu’est-ce que la clean archi ?

La Clean Architecture est une façon de concevoir les couches d’un système logiciel. Les règles écrites dans le livre « Clean Architecture : A Craft man’s Guide to Software Structure and Design » par Robert C. Martin viennent mettre les mots sur le concept.

Selon l’auteur, quelques soient les langages, les systèmes consistent à mettre en relation des blocs de construction de programme. Et ces blocs de code sont tous fait de if, d’affectations et de boucles while.

Comme le code est fondamentalement le même, les règles n’ont pas changé depuis le début de l’informatique et sont universelles à tous les types de systèmes.

Divers modèles ont été définis ces dernières décennies sur le sujet de l’architecture logicielle : architecture hexagonale, en oignon, DCI… Tous ces modèles ont en commun la volonté de séparer les responsabilités.

II. Pourquoi l’utiliser ?

La Clean Architecture vise à réduire les dépendances de votre logique métier avec les services que vous consommez (API, base de données, framework, librairies tierces) pour maintenir une application stable au cours de ses évolutions, de ses tests mais également lors de changements ou mises à jour des ressources externes.

La clean archi a pour but de rendre un système suffisamment facile à développer et à maintenir pour nécessiter le moins de main d’œuvre possible sur le long terme.

Un parallèle peut être fait avec le secteur du bâtiment, où l’architecture est une étape qui, si elle n’était pas présente, rendrait la construction du bâtiment bien plus chronophage et coûteuse, et laisserait les éventuels problèmes restant après la construction très compliqués à traiter.

A priori, il n’y a aucun inconvénient à utiliser la clean archi sur son projet.

III. Quelles sont ses limites ? Le coût de mise en place est-il adapté tous types, toutes tailles de projets ?

De par mon expérience de jeune développeur, j’ai déjà pu constater que, sur un projet de taille relativement importante, l’approche de la clean architecture sur sa structure a permis de réfléchir à la séparation des responsabilités entre chaque composant, des dépendances entre eux, et de dégager une organisation logique qui facilite la compréhension globale du projet.

Il s’agissait du cas d’un micro-service dont le rôle était d’agréger des données à partir d’autres micro-services de différents domaines, pour afficher les informations dans une interface après simplification (on appelait ça un micro-service-for-front).

Cependant je ne pense pas que la clean archi soit une nécessité sur des projets de taille moins importante… tant qu’ils ne sont pas destinés à s’agrandir par la suite. Mettre en place une clean architecture a tout de même un coût en temps de réflexion. La question qui en découle donc : à partir de quel moment devient-il pertinent d’envisager une clean archi ?

La réponse dépend de l’effort dont on estime avoir besoin pour maintenir le système au bout d’un certain temps. Une entreprise qui a besoin de recruter d’autres développeurs pour maintenir un système applicatif aura sans doute moins prêté d’importance aux efforts préliminaires de conception qu’à la rapidité de livraison.

Une nuance est également évoquée dans ce court article qui met en garde contre le « trop clean », le risque de trop se focaliser à la propreté du système, ce qui contraindrait l’aisance de développement d’un projet.

• msf = agrégation de données de multiples micro-services, transformation de cette donnée à destination d’un front.
• transformation de données métier => d’un côté des entities qui viennent du domaine, de l’autre des objets « presenters » qui sont des objets portant de la donnée mais qui interviennent après la logique de transformation (service layer) et avant l’interfaçage avec l’API (controller layer).
• où placer ces derniers objets dans la structure du système ?

Conclusion

La Clean Architecture est-elle donc indispensable aujourd’hui ?

Ma réponse est non. Un système peut tout à fait se passer de ce modèle et fonctionner en étant performant. C’est d’ailleurs de cette manière que les projets démarrent la plupart du temps.

Mais… ! Viendra sans doute un moment lors de la couverture de tests, la croissance de la volumétrie, l’ajout de complexité, l’intégration d’outils extérieurs, où il deviendra difficile de modifier des composants, expliquer le fonctionnement du système, faire du TDD ou juste tester les composants individuellement si l’architecture n’a pas pensé à tout cela. La clean archi vient proposer une solution en s’appuyant sur des principes universels. Il parait donc censé de penser en amont à quels efforts elle pourrait épargner à l’équipe de développement.

Pour aller plus loin

« The Clean Architecture » - https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

« Too Clean » - https://blog.cleancoder.com/uncle-bob/2018/08/13/TooClean.html

Source définition : https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html