Discussion :

[nanou2002]

Je travaille actuellement sur le développement d'une appli pour mon entreprise.
Cette appli sera développée sur une architecture en couches avec une modélisation du métier basée sur DDD (Domain Driven Design).

Mon approche est centrée sur ces uses cases. Je souhaite mettre en oeuvre les phases suivantes :

• spécifications
• analyse
• conception
• implémentation

Je souhaite au niveau de la couche métier ( le domaine ) mettre en oeuvre une couche de services "au dessus" des classes métier .Un service ( interface + implémentation) correspondant à un use case. Ces services sont directement utilisables par la couche de présentation (IHM web basée sur l'architecture MVC : framework Struts )

Mon problème est le suivant : dois-je faire apparaitre cette couche au niveau de la phase d'analyse ( donc prise en compte des classes de service au niveau du diagramme de classes d'analyse) ou alors au niveau de la phase de conception ( intégration des classes de service dans le diagramme de classes de conception ).

Pour moi, je pense que les services sont des choix de conception c'est à dire qu'ils ne font pas partie du travail de l'analyste qui lui se concentre sur les objectifs purement métier du système.
Je souhaite avoir votre avis sur le sujet.
Si quelqu'un pense autrement, je suis preneur de tout autre point de vue.

J'espère que j'ai été assez clair sur la problématique.

Merci d'avance

[Jacti]

Comme personne n'a répondu, bien que je n'ai pas trop de temps, je vais donner quelques indications.
Je dois préciser que je me situe dans une approche SOA (Architecture orientée services).
Tu dis que les services correspondent à des use cases. Il font donc partie des aspects métiers. L'analyse se focalise sur les aspects métier justement. Cette couche services fait partie de l'analyse et non de la conception.

Dans une architecture orientée services, on va partir des processus métier. Ils seront représentés par des diagrammes d'activité UML. D'autre part, les "objets" métiers vont fournir des "services" au sens activités d'un processus métier. Les services (au sens SOA) vont se trouver dans une couche au-dessous des processus métier mais au-dessus des objets métiers dont ils vont orchestrer les services exposés (ceci permet le faible couplage entre objets métier qui n'appellent donc jamais directement des services d'autres objets métier. On passe toujours par un orchestrateur au niveau services métier pour enchaîner des activités de différents objets métier). Dans une SOA, les objets services métier seront implémentés sous forme de "Web Services". Il ne faut pas confondre les services offerts par les objets métier (qui sont en fait des activités (les activités du diagramme d'activités) des processus métier) avec les "services métier" qui les orchestrent.
Les objets processus métier fourniront des méthodes qui orchestrent l'enchaînement des services métier.
Que reste-t-il, dans cette approche, à la conception ?
La conception va détailler l'architecture de chaque objet métier. En fait, un objet métier complexe va être constitué de plusieurs composants logiciels (un composant se traduira par un package au niveau implémentation).
La conception va aussi montrer comment chaque objet métier, objet service et objet processus se réparti sur chacune des couche du modèle N-tiers.
Un objet métier aura, au minimum, une couche présentation, une couche "applicative" et une couche données (avec utilisation du design pattern DAO pour rendre l'implémentation des données indépendante de la aprtie applicative).
Un objet service métier aura, au minimum, une couche présentation et une couche applicative (l'orchestration des activités des objets métier)
Un objet processus aura une couche "applicative" seulement qui orchestre les services métier.
Dans une approche SOA avec développement en composants, tout ce beau monde va se retrouver sous forme de package mais, au moins les services métiers seront développés en Web Services.
Un objet métier pourra être décomposé en plusieurs composants 1) s'il est complexe et/ou 2) si des parties peuvent être factorisées et distribuées en réseau.

J'espère que c'est assez clair bien que l'architecture globale que j'ai décrite ici soit relativement compliquée.

[nanou2002]

Merci pour ta réponse mais je ne me place pas dans une approche SOA. Ma couche de service est uniquement développée à base de POJO(s).

[trungsi]

C'est quoi le but de la phase d'analyse, en faite? Désolé de mon ignorance car je ne suis pas à la lettre ce processus dans mes devs quotidiens . Pour moi, je fais un peu de spec, un peu de dev, puis un peu de spec, un peu de dev... Dans le dev, il y a un peu de conception, des codes, et des tests. Dans la conception, je concois des objets métiers (entity, value object, repository,..) puis des factories, des services,... C'est donc dans la phase de conception où on applique le DDD.

[ego]

En analyse, on ne parle pas de couches.
En analyse, effectivement, on se concentre sur la logique métier = données et traitements métier.
Pour modéliser les traitements, il y a 2 écoles :
1- On ne crée pas de contrôleurs ou classes "services" car ces classes peuvent effectivement être vues comme des choix de conception. On crée donc des classes "données" (entity) et c'est dans des diagrammes de séquences que l'on va modéliser les traitements en partant du principe que l'on enverra les messages aux classes "données" les plus succeptibles d'être à même de traiter les dits messages. A ce stade, on ne fait pas de supposition sur qui sera effectivement responsable d'un traitement = qui supportera les opérations (soit les classes "données" soit des classes "service / contrôleur")

2- L'autre école est d'identifier très tôt des classes "service / contrôleur" qui se chargeront de réaliser les traitements. Sachant que dans ce cas, on va aussi se poser la question de savoir si des classes "données" ne doivent pas être responsables de traitements. Le risque ici est de se prendre trop la tête à inventer des classes "services" qui risquent d'être revues en conception. On risque donc, au moment où on réfléchit au métier, à se concentrer effectivement sur des problématiques de conception qu'il n'est pas forcément pertinent de prendre en considération pour le moment.

En fait, je pense que les 2 approches sont valables en fonction des contextes.

L'approche 1 est valable quand le métier est complexe ou on ne le conait pas très bien et/ou qu'on n'a pas encore une idée claire sur les responsabilités que pourront avoir telle ou telle classe en conception.

L'approche 2 est valable quand le métier n'est pas très complexe ou qu'on le connait bien et/ou on a une idée claire des responsabilités que les classes pourront avoir en conception. Attention à ne pas être trop prétentieu ici et à ne pas bruler les étapes.


Pour tes services au "niveau" des cas d'utilisation, fais attention quand même à la responsabilité de ces classes. Ce n'est pas forcément elles qui feront effectivement les choses, penses entre autres aux opérations utilisées dans le contexte de plusieurs cas d'utilisation. Cette approche, qui peut être assez similaire à l'approche 2 semble rassurante car on a l'impression d'avoir créé un lien entre le monde fonctionnel/métier et l'approche objet. Il ne faut pas oublier que la description fonctionnelle (les cas d'utilisation) d'une application est orthogonale à la description objet de l'application. Oui, ça fait un peu pompeu et savant mais c'est quand même vrai. Et cela veut dire que le lien entre cas d'utilisation/exigences est un peu plus complexe que la simple création d'un "contrôleur de cas d'utilisation".

Bref, au final, et malgré mes remarques précédentes, je suis a priori plus favorable à l'approche 1. C'est en conception que je verrai où il est pertinent de mettre les différentes responsabilités = quelles sont les classes qui supporteront les différents traitements (car tout peut changer en fonction de l'architecture choisie).