5 couches applicatives est-ce trop?
Jusqu'à ce jour, j'ai vécu bâtissant des applications fondées sur architecture à cinq couches applicatives: persistance, domaine, service, coordination, IHM.
Avec pour simplifier grossièrement, les contrats suivants pour ces couches:
Sur la base d'une expression de besoins et d'une analyse fonctionnelle établie par des utilisateurs et des analystes fonctionnels décrivant leurs problèmes avec précision,
De portée "Entreprise":
Service:
Plusieurs services, représentant ceux qui existent dans l'entreprise (Service courrier, service comptabilité, service expédition...) présentent leurs fonctions, c'est à dire ce qu'ils se disent capables de rendre comme service à l'ensemble [ou à certains acteurs seulement] de l'entreprise lorsque l'on fait appel à eux.
Ils implémentent les cas d'utilisation qui sont ressortis de l'expression de besoins. Chaque point d'entrée d'un service est un cas d'utilisation, qui se fonde sur les règles de gestion décrites dans l'analyse fonctionnelle pour autoriser des opérations réclamées par divers acteurs à avoir lieu.
Domaine:
Ce que manipulent les acteurs au quotidien dans l'entreprise pour répondre à leurs tâches professionnelles. Client, Facture, Bon de commande, Bon de Livraison, Bon d'expédition, Produit, Transport...
Un objet figurant dans la couche domaine est un objet métier. Il ne peut s'y trouver que si un utilisateur au moins le comprend intégralement. Un objet "technique" d'informaticien ne devrait pas s'y trouver.
Avec dès cet endroit une règle d'essence "Test Driven" qui dit qu'à partir du moment où l'on sait ce que l'on a (les objets métiers) et que l'on sait ce que l'on doit faire (les services que l'on peut rendre) on peut déjà décrire intégralement ce qui sera mis en place et préparer ses tests.
Domaine + Services = tout ce que sait faire l'entreprise.
Persistance:
La manière dont les objets de la couche domaine (essentiellement) sont placés, relus, et détruits d'un support quelconque. Ce support n'est pas forcément une base de données.
Cette couche ne connaît pas le métier de l'entreprise. Elle ne sait pas préjuger si une opération d'E/S qui lui est demandée a un sens ou non du point de vue de l'analyse fonctionnelle ou de l'expression des besoins.
Il y est fait souvent usage de Data Access Objects (DAO) dont le but est de masquer la nature du support physique à celui qui les emploie, tout en représentant d'éventuels problèmes survenus sur le support de la manière qui aidera le plus possible l'appellant.
Sauf excès de rigueur de ma part, seule la couche service est habilitée à réclamer des opérations sur les supports physiques. Elle est la seule à apercevoir la couche persistance.
De portée "Application":
(une entreprise utilise plusieurs applications)
Coordination:
Comment une application se représente la résolution des problèmes auxquels elle doit répondre.
Elle doit composer avec les cas d'utilisation présentés par l'entreprise. Et ceux-là peuvent lui convenir parfaitement ou réclamer d'elle des circonvolutions.
Cette couche est porteuse du modèle, sorte d'intelligence équivalente à celle de la couche service, mais à la hauteur du client.
Cette couche a aussi la possibilité de provoquer ou de réagir à des évenements venus d'interfaces homme-machine.
Interfaces homme-machine (IHM)
Les interfaces graphiques (le plus souvent) la manière dont l'utilisateur réalise ses demandes à son application.
Toutes ces définitions sont mes perceptions de leurs rôles, que vous pouvez corriger ou compléter selon vos propres compréhensions.
Cependant, régulièrement, je vois cette répartition remise en cause.
Soit par des frameworks qui semblent ignorer la couche service (JBoss Seam?) soit par l'arrivée de mécanismes comme ceux des entity beans qui associent objets de la couche domaine et persistance en un seul constituant.
Dans ce cas, je me dis: aujourd'hui, allons-nous vers une diminution du nombre de couches applicatives?
Mais si je me mets à un autre angle, et que je dis: mes couches domaine et service sont les plus importantes à mes yeux, elles sont définies de manière indépendante de toute base de données et de tout protocole de communication (ce qui me semble l'idéal), alors je suis amené à:
- Créer des objets dégradés (Data Transfert Object: DTO) pour représenter le contenu d'une base de données, par exemple, qui ne s'accorde pas très bien avec mon modèle objet (une base ancienne par exemple).
- Je suis amené à en créer aussi si le transport d'objets métiers à destination du client est:
. Soit trop consommateur en temps et en ressources, et qu'il faut diminuer la quantité d'informations échangée.
. Soit trop révélateur du fonctionnement de l'entreprise: à un web service appelé par je ne sais qui dans le monde, je ne veux pas remettre des objets qui portent déjà en eux une certaine "puissance logique".
Dans ce cas, je me demande si plutôt que de diminuer les couches applicatives, cela n'en crée pas une sixième, destinée aux échanges (je suis le premier à penser que ce mot n'est pas très heureux... j'en cherche un autre).
Quels sont vos avis/réflexions sur l'emploi des couches logicielles?
Sur le bien fondé qu'il y aurait que certaines disparaissent, ou au contraire, soient ajoutées?
Répondre avec citation
, 
ni 
, ne peuvent vous aider, mais nous oui, pensez à un pti 
et au 
! 
Partager