jeudi 6 mars 2008

L'architecture à 5 couches

Une pratique répandue dans l'architecture d'une application de gestion, est d'utiliser une solution à 5 couches.

Qu'est-ce qui caractérise une application de gestion ?

Une application de gestion, comme son nom l'indique, doit gérer des données. Ce qui implique l'utilisation d'une base de données (la plupart du temps relationnel). Cela implique également une interface pour permettre à des gestionnaire de voir et modifier ces données.

Tout n'est pas assimilable à une application de gestion. Il y a des besoins d'informatiques embarqués, d'informatiques industriel, des logiciels utilitaires, etc.. Dans ces cas là, le découpage en 5 couches ne s'appliquent pas.

Pourquoi distinguer des couches?

Le but de la conception en général, est d'attribuer des responsabilités. Définir des couches est un moyen de séparer les responsabilités et ainsi, de minimiser l'impact du changement.

Maintenant que l'avertissement est donné, je vais clarifier le rôle de ces 5 couches.



  1. la couche Présentation
    Cette couche est l'apparence visuelle de l'application, telle qu'elle sera perçue par l'utilisateur finale. C'est ici que vous aurez les images, les pages JSP, etc..
  2. la couche Coordination
    Ici vous avez les contrôleurs du pattern MVC. C'est à dire des composants qui interceptent les interactions de l'utilisateur et qui gère la cinématique (ou logique) des écrans.
  3. la couche Service
    La couche Service regroupe tous les services, ou réalisation de cas d'utilisation. L'idée est d'exposer ces services pour différentes applications clientes. On peut retrouver dans cette couche les Web Services d'une architecture SOA ou les service RESTful. On peut également trouver des EJB session, si le SI est en pure Java.
  4. la couche Métier (ou Domaine)
    La couche Métier reprend tous les objets métiers de l'application considérée. C'est ici qu'est portée la logique des règles de gestion sur ces objets. On peut trouver des EJB session, mais non exposés au monde extérieur.
  5. la couche Persistance
    La couche Persistance est la couche qui sert de communicateur avec la base de données. Son avantage est le rôle de sas de sécurité entre l'application et la base de données. Si la structure de données change, seule (en théorie) cette couche est à modifier. On trouve ici des entités persistantes (JPA, Hibernate ou EJB entity).
Chaque couche a seulement la permission d'appeler la couche suivante (ainsi, la couche Présentation, ne peut utiliser/récupérer/instancier/etc.. que des objets de sa propre couche ou de la couche Service, et à l'autre bout, la couche Persistence ne peut utiliser que des objets de sa propre couche)

Les raisons d'être des couches. L'avantage de la couche Métier est que les règles de gestion (RG) sont regroupés à un seul endroit. La couche persistance n'est pas parasitée par ces RG. Elle peut par exemple récupérer une entité en base, et la couche Métier peut la déclarer invalide (si elle casse une RG) et lancer une exception.

L'avantage de la couche Service est qu'elle orchestre l'appel aux objets métiers, nécessaires pour l'accomplissement du service (et donc du cas d'utilisation). De ce fait, elle gère l'aspect transactionnel des choses, c'est à dire l'assurance qu'un service s'effectue en totalité ou pas du tout. C'est donc la couche Service, qui doit demander une connexion à la base de données, et la configurer pour ouvrir (si besoin est) une transaction.

L'avantage de la couche Coordination, est qu'elle orchestre l'appel aux différents services, par le pilotage d'un processus. De ce fait, elle peut elle aussi gérer l'aspect transactionnel mais au niveau inter-applicatifs.

Par exemple, imaginons qu'on ait un service S1, qui fasse un travail d'update sur une base de données B1. Et qu'un service S2, fasse un autre travail d'update sur une base de données B2. Si l'on a une exigence que les 2 bases soient cohérentes l'une par rapport à l'autre, et si jamais une modification sur B2 n'a pas pu avoir lieu, il faudra défaire la modification sur B1.

C'est donc à cette couche Coordination de gérer cela, en détricotant elle-même les modifications antérieures.

Enfin, nous pouvons trouvons une couche Transverse, contenant tous les objets accessibles par l'ensemble des autres couches. Cette couche contiendra des objets valeurs et différentes classes utilitaires (de date, de chaîne de caractères, etc..)

1 commentaire:

Laurent LO a dit…

Bonjour,

Peut-on parler de design patern MVCS du coup ?

Cordialement,
Freelance prestashop