Ressources
L’architecture en couches (Layered Architecture) est l’un des styles architectural les plus populaires. L’article suivant Reevaluating the Layered Architecture présente pourquoi ce style c’est largement imposé dans le monde logiciel.
Topologie
Dans le style d’architecture en couches, les composants sont organisés en couches techniques (en opposition au domain-partitioned architecture), chaque couche jouant un rôle spécifique au sein de l’application. Malgré que le nombre de couches peut varier, la majorité des architectures sont composées de quatre couches :
- Presentation
- Business/Persistance qui peuvent être combinées en une seule
- Database
Separation of Concern
L’architecture en couches respectent le principe de Separation of Concern en rendant chaque couche responsable. Les composants au sein d’une couche spécifique ont un périmètre limité, ne traitant que la logique qui se rapporte à cette couche. Par exemple, les composants de la couche de présentation ne traitent que la logique de présentation, tandis que les composants résidant dans la couche métier ne traitent que la logique métier.
Layers of Isolation
Définition
Le concept de Layers of isolation signifie que les modifications apportées à une couche de l’architecture n’ont généralement pas d’impact ou d’incidence sur les composants des autres couches.
Pour garantir ce principe, les couches doivent être fermées (closed), c’est-à-dire que lorsqu’une requête se déplace de haut en bas d’une couche à l’autre, elle ne peut sauter aucune couche. Si vous autorisez la couche de présentation à accéder directement à la couche de persistance, les modifications apportées à SQL dans la couche de persistance auront un impact à la fois sur la couche métier et sur la couche de présentation, ce qui produira une application très étroitement couplée avec de nombreuses interdépendances entre les composants.
En ayant des couches indépendantes, si on souhaite remplacer une technologie sur une couche par une autre (e.g. JSF par React.js) cela n’impactera pas les autres couches.
Déploiement
Depuis les années 60, l’architecture en couche a évolué est sa stratégie de déploiement avec. La première variante combine les couches de présentation, métier et de persistance en une seule unité de déploiement. Puis des déploiement plus complexe sont apparues (n-tiers) 1
Ce que n’est pas une architecture en couche
Couches métiers
En début de page nous avons souligné le fait que les composants sont organisés en couches techniques en opposition au domain-partitioned architecture. Chaque domaine (e.g. un Client, une Facture) est représenté dans les trois couches. L’inconvénient réside dans le fait que si nous modifions les règles du domaine, nous devrons impacter les trois couches.
Par conséquent, une approche Domain Driven n’est pas des plus compatible avec le style architectural Layered. Une variante consiste à retravailler l’architecture en couches vers une Vertical Slice Architecture