La "Clean Architecture", bien plus qu'une arborescence de fichier

Une grande partie des projets informatique, que j’ai pu voir au cours de ma carrière, conçue autour d’une architecture hexagonale, était bien souvent plus proche d’une clean architecture en pratique. Cette dernière, est souvent découpée en plusieurs couches qui sont Domain, Application ou UseCase, Infrastructure et plus rarement UserInterface, sont une représentation physique des couches évoquées par Robert C. Martin qui a théorisé cette architecture.

Beaucoup sont attachés à la représentation physique de ces couches. Pour autant, la clean architecture ne se résume pas à un simple découpage du code. Le principe fondamental de cette architecture repose en réalité sur le sens des dépendances et non sur la matérialisation des couches du code.

Preuve en est, si vous prenez le livre de référence “Clean Architecture: A Craftsman’s Guide to Software Structure and Design: A Craftsman’s Guide to Software Structure and Design” (lien non affilié), sur les un peu plus de 370 pages du livre, 8 pages sont consacrées au découpage des couches représenté par le diagramme ci-dessous et qui pourtant sert à résumé ce qu’est la clean architecture dans 90% des articles du Web.

Les couches présentes sont généralement représentées par l’arborescence suivante:

.
└── src
    ├── ContexteMetier1
    │   ├── Application
    │   ├── Domain
    │   ├── Infrastructure
    │   └── UserInterface
    └── ContexteMetier2
        ├── Application
        ├── Domain
        ├── Infrastructure
        └── UserInterface

Et pour beaucoup, la clean architecture se résume à ce découpage.

Pourtant, comme je l’ai rapidement indiqué en introduction de ce billet, le principe fondamental de la clean architecture est le sens des dépendances, ces dernières devant pointer vers l’intérieur du cercle. Dis autrement, les couches métiers (Domain) contenant les règles métier ne doivent pas dépendre du code qui implémente les détails techniques (les couches extérieures). Concrètement, cela signifie que vos objets métiers (tel qu’une Commande ou une Facture) ne devraient avoir connaissance ni de l’ORM, ni du Framework utilisé. La couche Application qui orchestre les cas d’utilisation peut connaître les objets métier, mais reste indépendante des éléments d’infrastructure, tels que le client HTTP utilisé. Seule cette dernière couche, la couche se trouvant à l’extrémité des dépendances peut dépendre de frameworks et autres outils techniques (tel que Guzzle ou Symfony HTTP Client dans le cas d’un client HTTP).

Ce sens des dépendances est notamment illustré par le principe SOLID donc les différentes notions sont présentées de manière détaillée dans le livre. C’est le cas du principe d’inversion des dépendances qui contribue à la flexibilité et à la modularité du code face aux changements et aux évolutions du code.

Respecter les principes précédents permettent de mieux découper et isoler la logique métier permettant de faciliter l’écriture des tests. Les éléments techniques étant isolés, il devient facile de remplacer une implémentation d’une base de données ou d’un composant technique offrant une résistance au changement. La compréhension du code est facilitée du fait que le coeur de l’application est mis en valeur par l’absence de bruit technique et se concentre ce qui a de la valeur pour le métier.

Si la clean architecture ne repose finalement pas sur une arborescence de dossier, cela reste néanmoins un outil pratique pour matérialiser, visualiser et se repérer dans les différents éléments du code. L’arborescence permet de rendre visible la séparation des différentes couches qui composent l’architecture. Elle permet de créer une convention d’équipe qui simplifie la revue du code, la collaboration entre développeurs et participe à l’uniformisation des pratiques. Elle permet également de faciliter la mise en place des contrôles de cohérence d’architecture avec des outils tels que Deptrac.

Ne résumez pas la clean architecture a une arborescence de fichier. Cherchez avant tout à isoler le métier des dépendances techniques. Créez une architecture et un code résilient face au changement et qui soit capable d’évoluer sans friction au cours du temps. Néanmoins, je reste convaincu qu’il est important que votre architecture puisse se rattacher à des principes et concepts de base et connu d’un grand nombre, permettant de trouver facilement de l’information dans la littérature.