BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles L'Architecture En Couches, Toujours La Norme?

L'Architecture En Couches, Toujours La Norme?

Favoris

Points Clés

  • L’architecture en couches possède des problèmes inhérents, pourtant elle semble toujours être la norme.
  • La résolution de ces problèmes permet de faire évoluer l’architecture en couches vers des architectures de la famille de la “Clean Architecture”.
  • Privilégier les architectures de la famille de la “Clean architecture” (en particulier pour des microservices métier)

Les styles architecturaux côté backend semblent depuis des années être dominés par le modèle en couches (présentation, service et persistance). Avec l'avènement des microservices et après la parution par Robert C.Martin de la "clean architecture" dans son blog en 2012 (The Clean Architecture), puis dans dans son livre éponyme en 2017, on aurait pu penser qu'un changement de dominance allait survenir. Ce n'est pour l'instant pas le cas, la faute peut être dû au fait que la "clean architecture" reste abstraite pour beaucoup et pas facilement implémentable. Dans cet d'article, nous verrons les problèmes inhérents à l'architecture en couches et comment il est possible de les résoudre par l'utilisation d'une architecture de type "clean architecture".

Problématiques de l'architecture en couches

Nous allons commencer par présenter les problématiques que l'on peut rencontrer avec l'utilisation de l'architecture en couches (Fig 1).

Fig 1. Architecture en couches

 

À court terme, dès la création du projet, nous allons de par l'orientation des dépendances avoir tendance à démarrer par la couche de persistance. Le sens des dépendances à une importance primordiale (cf. Dépendances Et Valeur Métier Au Cœur De L'Architecture) et la fondation de l'architecture en couches se trouve être celle de persistance. Ce simple sens de dépendance entraîne des questionnements survenant trop tôt dans la vie d'un projet, tel que le moyen de persistance ainsi que son modèle de données. Il s'agit du type de décision qui doit pouvoir être repoussé afin de laisser les options ouvertes et ainsi connaître au mieux les enjeux fonctionnels et non fonctionnels lors du choix. De plus, un changement dans la couche de persistance aura de forts risques d'avoir un impact sur la couche service, qui aura un impact sur la couche présentation (Fig 2).

Figure 2 : Impact d'un changement dans la couche de persistance (Couplage fort)

L'objectif principal du développement est et reste la compréhension et la résolution des problématiques métiers. Idéalement, seulement un changement du métier devrait avoir un impact sur l'ensemble de l'architecture. L'architecture en couches ne permet pas de repousser à plus tard les choix techniques et ainsi garder les options ouvertes. Elle nous éloigne de la partie métier dès le début du projet.

À moyen terme, un effet de bord récurrent de l'architecture en couches apparaît avec le "gonflement" de la couche de service. Une des conséquences les plus visibles est l'évolution de certaines classes de services en "GOD objects" possédant trop de responsabilités à gérer. Ceci entraîne une difficulté à se retrouver dans le code et à terme un problème de maintenabilité. Une autre conséquence de ces "GOD objects" dans la couche service est la difficulté accrue à travailler à plusieurs d'une même équipe en même temps sur le même projet. Un risque élevé existe de se retrouver à travailler sur la même classe ce qui peut être source de conflit et de perte de temps.

On constate que ce soit à court ou à moyen terme dans la vie d'un projet, l'architecture en couches nous apporte son lot de problèmes. Pourtant, cette architecture continue d'être majoritairement utilisée.

Évolution de l'architecture en couches vers la "Clean architecture"

Est-ce parce qu'il n'existe pas de solution pour remédier aux problèmes précédents ?

La réponse est évidemment non, et nous allons voir comment remédier aux problèmes précédents qui sont :

  1. Architecture non centrée sur le métier
  2. Choix des options techniques fermés
  3. Problème de maintenabilité
  4. Difficulté à travailler en parallèle

Construisons de manière itérative notre architecture idéale en ayant comme point de départ l'architecture en couche.

Pour avoir une architecture centrée sur le métier, ce que l'on cherche à obtenir, c'est d'avoir comme fondation, non pas une couche de persistance, mais une couche métier. Dans notre cas de l'architecture en couche, il s'agit pour l'instant de notre couche service. Pour effectuer ce changement, nous allons utiliser l'inversion de dépendances (cf. Dépendances Et Valeur Métier Au Cœur De L'Architecture), et nous obtenons l'architecture en couches v1 (Fig 3).

 

Figure 3 : Architecture v1 avec la couche service au centre en tant que fondation

Grâce à l'inversion de dépendance, nous avons résolu les deux premiers problèmes. La couche service ne dépend plus d'aucune autre couche, c'est notre nouvelle fondation qui met le métier au centre des préoccupations de l'équipe de développement. Les choix techniques d'implémentation (ex: type de persistance) restent désormais ouverts de par l'abstraction, inhérente à l'inversion de dépendance, se trouvant dans la couche service et l'implémentation se trouvant dans la couche de persistance.

Attaquons-nous au problème de maintenabilité lié au "gonflement" de la couche de service. Afin de "dégonfler" cette couche et de répartir sa charge, nous allons utiliser une couche additionnelle. Pour arriver à responsabiliser au mieux les différents objets, nous allons dédier cette nouvelle couche au domaine métier. Nous obtenons une architecture en couche v2 (Fig 4).

 

Figure 4 : Architecture v2 avec la couche domain

Avec ce changement, la couche service est désengorgée, ne faisant plus que de l'orchestration d'appel afin d'appliquer les règles métiers gérées par des objets de la couche domaine, la maintenabilité s'en retrouve améliorée.

Dernière problématique à résoudre, améliorer le travail en parallèle. Avec notre architecture v2 nous avons déjà amélioré ce travers de l'architecture, mais nous pouvons faire mieux. Ce que l'on souhaite, c'est de pouvoir développer en parallèle différents "use cases" avec le moins de friction possible. Nous allons utiliser dans les principes SOLID le principe de "Single Responsability”, qui je le rappelle ne signifie pas être responsable d'une seule "chose" mais que la classe n'a en théorie qu'une seule raison de changer. Nous appliquons ce principe à la granularité du "use case" en exposant une abstraction par "use case" ("Use Case as first class citizen", Robert.C Martin), ce qui nous donne notre version finale de l'architecture v3 (Fig 5).

 

Figure 5 : Architecture en couche v3, avec les "Use cases as first class citizen”

 

Pour ceux connaissant déjà la "Clean Architecture" et/ou l' "Hexagonal Architecture", on constate que nous en sommes très proche, tout est une question de représentation (Fig 6).

 

Figure 6 : Architecture v3 sous la représentation de la "Clean Architecture” puis de "l'Hexagonal Architecture"

Nous venons, à la suite de plusieurs itérations, d'obtenir une architecture qui comble les problématiques de l'architecture en couches. Nous avons montré ensuite qu'elle n'a rien d'original puisqu'elle est compatible avec les représentations de la "Clean Architecture" et de l'architecture hexagonale.

Ces architectures règlent les problèmes de l'architecture en couches, mais alors pourquoi ne sont-elles pas plus utilisées ? Est-ce la peur du changement ? Sont-elles trop complexes à mettre en place ?

En ce qui concerne la peur du changement, c'est en effet un facteur qui peut exister. Dans des entreprises possédant des bases de codes conséquentes utilisant l'architecture en couches, la tentation est grande de justifier de garder cette architecture afin de garantir une homogénéité entre les projets et ainsi "faciliter” l'adaptation de futurs développeurs venant d'autres projets. Même si ce choix peut s'entendre, il va à l'encontre des principes permettant l'innovation, et l'on sait que c'est souvent par l'innovation que l'on peut soit se démarquer, soit rester au même niveau que la concurrence.

Est-ce trop complexe ? Après 3 ans de pratique quotidienne de l'architecture hexagonale sur plusieurs microservices, je peux dire qu'elle n'est ni plus complexe ni plus coûteuse. Il y a cependant un temps de montée en compétences plus important pour de nouveaux venus du fait que ce ne sont pas des architectures communément utilisées. Temps qui est largement compensé par les gains apportés par l'utilisation de ce type d'architecture.

Conclusion

En conclusion, pour les nouveaux projets démarrant avec une architecture en couches (en particulier pour des microservices métier), je ne peux que vous encourager à challenger celle-ci et à utiliser une architecture de la famille de la "clean architecture" !

Au sujet de l’Auteur

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT