Concepts clés
Notez dans la figure 1-2 que chacune des couches de l’architecture est marquée comme étant fermée. Il s’agit d’un concept très important dans le modèle d’architecture en couches. Une couche fermée signifie que lorsqu’une demande se déplace d’une couche à l’autre, elle doit passer par la couche juste en dessous pour atteindre la couche suivante. Par exemple, une requête provenant de la couche de présentation doit d’abord passer par la couche métier, puis par la couche de persistance avant de toucher enfin la couche de base de données.
Figure 1-2. Couches fermées et accès aux requêtes
Alors pourquoi ne pas autoriser la couche de présentation à accéder directement soit à la couche de persistance, soit à la couche de base de données ? Après tout, l’accès direct à la base de données depuis la couche de présentation est beaucoup plus rapide que de passer par un tas de couches inutiles juste pour récupérer ou enregistrer les informations de la base de données. La réponse à cette question réside dans un concept clé connu sous le nom de couches d’isolation.
Le concept de couches d’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 : la modification est isolée aux composants de cette couche, et éventuellement à une autre couche associée (comme une couche de persistance contenant SQL). 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, produisant ainsi une application très étroitement couplée avec de nombreuses interdépendances entre les composants. Ce type d’architecture devient alors très difficile et coûteux à modifier.
Le concept de couches d’isolation signifie également que chaque couche est indépendante des autres couches, ayant ainsi peu ou pas de connaissance du fonctionnement interne des autres couches de l’architecture. Pour comprendre la puissance et l’importance de ce concept, considérons un grand effort de refactoring pour convertir le cadre de présentation de JSP (Java Server Pages) à JSF (Java Server Faces). En supposant que les contrats (par exemple, le modèle) utilisés entre la couche de présentation et la couche métier restent les mêmes, la couche métier n’est pas affectée par le remaniement et reste complètement indépendante du type de framework d’interface utilisateur utilisé par la couche de présentation.
Bien que les couches fermées facilitent les couches d’isolation et aident donc à isoler les changements au sein de l’architecture, il y a des moments où il est logique que certaines couches soient ouvertes. Par exemple, supposons que vous souhaitiez ajouter une couche de services partagés à une architecture contenant des composants de services communs auxquels accèdent les composants de la couche métier (par exemple, des classes utilitaires de données et de chaînes ou des classes d’audit et de journalisation). La création d’une couche de services est généralement une bonne idée dans ce cas car, d’un point de vue architectural, elle limite l’accès aux services partagés à la couche métier (et non à la couche de présentation). Sans une couche séparée, il n’y a rien architecturalement qui restreint la couche de présentation d’accéder à ces services communs, ce qui rend difficile de gouverner cette restriction d’accès.
Dans cet exemple, la nouvelle couche de services résiderait probablement sous la couche métier pour indiquer que les composants de cette couche de services ne sont pas accessibles depuis la couche de présentation. Cependant, cela pose un problème dans la mesure où la couche métier doit maintenant passer par la couche services pour accéder à la couche persistance, ce qui n’a aucun sens. C’est un problème séculaire avec l’architecture en couches, et il est résolu en créant des couches ouvertes dans l’architecture.
Comme l’illustre la figure 1-3, la couche services est dans ce cas marquée comme ouverte, ce qui signifie que les requêtes sont autorisées à contourner cette couche ouverte et à aller directement à la couche qui lui est inférieure. Dans l’exemple suivant, puisque la couche services est ouverte, la couche métier est maintenant autorisée à la contourner et à aller directement à la couche persistance, ce qui est parfaitement logique.
Figure 1-3. Couches ouvertes et flux de demandes
L’exploitation du concept de couches ouvertes et fermées permet de définir la relation entre les couches de l’architecture et les flux de demandes et fournit également aux concepteurs et aux développeurs les informations nécessaires pour comprendre les diverses restrictions d’accès aux couches au sein de l’architecture. Le fait de ne pas documenter ou de ne pas communiquer correctement quelles couches de l’architecture sont ouvertes et fermées (et pourquoi) aboutit généralement à des architectures étroitement couplées et fragiles qui sont très difficiles à tester, à maintenir et à déployer.