La Clean Architecture, couteau suisse du code !

15 septembre 2021

Nul doute que la Clean Architecture est un sujet de plus en plus tendance depuis 2015. Loin d’être un simple effet de mode, c’est bien parce que son importance est capitale qu’elle devient une priorité pour de plus en plus de structures.

Dans un contexte technologique toujours plus compétitif, et toujours plus évolutif, il devient primordial de faire des choix techniques flexibles pouvant facilement être adaptés en cas de futures migrations. C’est précisément le but de la Clean Architecture, aussi appelée Hexagonal Architecture, qui rend chaque produit à la fois simple à tester unitairement et simple à migrer.

 

Qu’est-ce que la Clean Architecture ?

La Clean Architecture est un type d’architecture des systèmes proposé par Robert C. Martin (aka Uncle Bob) et présenté en détail dans son ouvrage Clean Architecture, A Craftsman’s Guide to Software Structure And Design.

Elle vise à rendre le code plus simple à maintenir, tester, et débogguer ; mais aussi et surtout, à le rendre plus évolutif.

Cette architecture consiste en une organisation en couches, chaque couche ayant des responsabilités bien définies. Son idée maîtresse est l’indépendance, qui garantit une flexibilité du code à tous points de vue.

 

La logique de la Clean Architecture se veut:

  • Indépendante des frameworks : les frameworks et librairies tierces doivent être pensés comme des outils, et non des cadres contraignants.
  • Testable indépendamment : les tests doivent pouvoir être réalisés sans dépendances entre les parties, et sans dépendances à des éléments externes (API, base de données …)
  • Indépendante de l’interface utilisateur : l’interface utilisateur doit pouvoir évoluer facilement .
  • Indépendante de la base de données
  • Indépendante de tout service ou système externe : en résumé, le code doit être indépendant des tierces parties dont il n’assure pas le contrôle.

 

La Clean Architecture donne une marge de manoeuvre incomparable par rapport à une architecture classique MVC.

Elle permet de ne plus être dépendant de tierces parties dans le développement, de changer de framework facilement sans avoir à subir de lourdes conséquences, d’intervertir des sources de données très simplement, mais également de réaliser des tests unitaires sans difficulté et d’obtenir ainsi des feedbacks rapides.

Cette organisation permet donc d’augmenter considérablement la productivité des développeurs.

 

L’organisation en couches

La règle de dépendance est au coeur du concept de Clean Architecture. Elle segmente entièrement les différentes couches, de sorte qu’une couche inférieure ne peut jamais dépendre d’une couche supérieure. Les classes, fonctions, variables d’une couche supérieure ne sont jamais mentionnées dans une couche inférieure. La dépendance ne s’envisage que d’une couche supérieure vers une couche inférieure.

Cette architecture permet de s’assurer que les changements apportés sur les couches supérieures n’aient aucun impact sur les couches inférieures, et donc de maintenir une application stable aussi bien au cours de mises à jour de ressources externes, que de tests ou d’évolutions (changement de frameworks, de base de données, etc.).

 

Les interactions entre les couches

Le schéma en bas à droite de la figure ci-dessus détaille le fonctionnement des interactions entre un « controller » de la couche d’adaptateurs d’interface (Interface adapters) et un cas d’utilisation (Use cases).

Puisqu’une couche supérieure peut avoir des dépendances dans les couches inférieures, un « controller » peut donc avoir un cas d’utilisation comme dépendance. L’inverse ne peut se produire, puisque la dépendance ne s’envisage que dans un sens.

 

Comment faire lorsqu’une couche inférieure a besoin d’une couche supérieure pour réaliser une tache ? Pour maintenir une séparation stricte des couches et respecter la règle des dépendances, on définit une interface dans la couche inférieure, qui sera implémentée par la couche supérieure.

Le schéma en bas à droite illustre ce cas précis : le controller dépend du Use case, via l’interface Use Case Input Port. L’interface Use Case Interactor implémente la fonctionnalité du Use Case Input Port. Jusqu’ici, pas de difficulté, car la dépendance a lieu dans le bon sens.

Mais l’interface Use Case Interactor a besoin du Presenter pour exposer les données de réponses, or le Presenter appartient à couche du dessus.

La création d’une interface dans la couche Use Cases (Use Case Output Port) permet de contourner cette dépendance avec la couche supérieure. L’Interactor dépendra de cette interface, et non directement du Presenter.

Grâce à cette interface, la classe chargée de récupérer les données (le « presenter ») peut tout à fait changer, sans que cela n’ait de répercussions sur le coeur de l’application.

Cette architecture évite soigneusement la création de dépendance avec les couches supérieures.

 

Les tests en Clean Architecture

L’architecture en couches indépendantes simplifie et fluidifie considérablement la réalisation des tests.  Le découplage entre le coeur applicatif et les tierces parties permet de tester le code couche par couche, sans avoir à faire appel à du code externe.

La Clean Architecture permet donc d’éviter à la fois les difficultés liées aux fortes dépendances entre les parties et celles liées aux dépendances à des API, dont les requêtes sont soumises à une latence plus ou moins importante.

Cette architecture créée donc un contexte hyper-favorable à la pratique du TDD (Test-Driven Development), dont on ne compte plus les bénéfices :

 

  • Meilleure lisibilité du code et meilleur confort de travail
  • Moins de fautes d’inattention laissées dans le code source
  • Quasiment plus besoin d’utiliser le mode debug
  • Gain de productivité
  • Gain d’évolutivité

Attention cependant à ne pas tomber dans les pièges de la sémantique séduisante du « TDD », qui est souvent employé à tord comme un terme racoleur aujourd’hui.

Michaël Azerhad, Président de Wealcome, met en garde contre ces excès en rappelant que le TDD doit répondre à des lois très précises pour porter ses fruits, notamment 3 « NO-GO » :

 

  • Pas le droit d’écrire du nouveau code en production, sauf pour faire passer un test qui échoue.
  • Pas le droit d’écrire plus d’un test que ce qui est suffisant pour échouer. L’erreur de compilation est considérée comme un échec.
  • Pas le droit d’écrire plus de code de production qu’il n’en faut pour réussir le test ayant échoué.

 

Conclusion

La Clean Architecture comporte des avantages inestimables qui rendent son utilisation toute indiquée pour rester compétitif sur un marché ultra-évolutif.

Sa rigueur ne laisse pas de place au désordre, et libère les développeurs de contraintes lourdes pour le rendre indépendant des frameworks, BDDs, librairies externes, ou encore des APIs.

Flexibilité, adaptabilité, évolutivité et productivité sont les avantages-clés d’une architecture qui a tout intérêt à continuer à se faire connaître par un plus grand nombre de développeurs.

L'auteur Aurélie Lecomte

Head of Marketing

Aurélie Lecomte
Postuler à l'annonce Postuler à toutes les annonces Ingénieur système linux orienté web
Remplissez le formulaire
C'est tout bon

On vous recontact au plus vite !
En attendant, vous pouvez toujours consulter nos autres jobs !

rotate screen

Retourner votre tablette pour une meilleure navigation