Discussion :

[michouhinda]

salut,

Je suis un apprenti de Model Driven Ddesign :

Je trouve des difficultés pour comprendre la différence entre Repository, Factory et service
Et comment puis-je les représenter dans un même modèle (par exemple sous ArgoUML) ,
De même j’arrive pas à comprendre la notion de ‘Boudary Aggregate’ ;

Quelqu’un peut m’aider ?? Peut être un lien ou une brève description ?

Merci d’avance

[Guérin Franck]

Bonjour,

Je pense que tu fais référence au Livre de Eric Evans ...

Un "Agregate" est un regroupement "d'entités" (et d'objets valeurs : Values Object) qui forme un tout cohérent - par exemple une facture/commande et les lignes la constituant. Généralement, une des entités de l'agrégat permet d'accèder aux autres entités de l'agrégat - ici accèder à la facture pour accèder à ses lignes.
En procédant ainsi tu peux créer des "petits ilots" (le terme est peut être mal choisi) bien délimités se focalisant sur un contexte donné (les bounded context).

Les factory sont les objets permettant de créer des entités ou des agrégats dans leur intégralité. Cela permet de masquer, aux utilisateurs de ces entités/agrégats, la manière de les créer et pour les agrégats leur structure interne.

Les repository sont les objets permettant retrouver (!= création) un ou un ensemble d'entités/agrégats au cours de leur vie.

Les services sont des responsabilités métiers difficilement affectable à une entité en particulier (parce qu'elle implique un ensemble d'entités par exemple) et que l'on décide quand même de factoriser dans la couche métier.
De ce fait, cette responsabilité n'appartenant à aucune une entité précise n'est pas duppliquée partout où l'on en a besoin - il suffit d'appeler le service.

En espérant avoir été clair.

Bon courage.

[michouhinda]

Bonjour,
merci bien, tout est clair.
J´ai un autre point qui n´est pas clair : concernant la specification.
lorsqu´on parle de la specification, donc on parle de quoi exactement : spec de repositories , de services ou de factories. et est ce qu´on peut realiser la specification en utilisant "The Object Constraint Language" OCL.

Merci d´avance

[Guérin Franck]

Je n'ai plus trop le livre en tête ... donc je ne vais peut être pas répondre à ton intérogation.

Il me semble que dans le livre, l'auteur faisait beaucoup usage du pattern Specification consistant à extraire des objets les "assertions" les caractérisant/définissant, en encapsulant ces assertions dans des objets Spécification exposant une interface permettant de vérifier si l'objet initial satisfait la spécification - opération du type EstSatisfaitPar(Obj).

Tu peux alors définir des règles métier valables uniquement si certaines spécifications sont vérifiées par l'objet ...

Ces objets spécifications peuvent être assemblés ensemble pour créer une spécification composite et constituer un "véritable petit langage" ...

Personnellement, ce pattern n'est pas la première idée me venant à l'esprit.

Remarque : Du fait que toutes ces spécifications reposent sur une même interface, tu pourrais même imaginer les plugger à l'exécution ...

Si tu es intéressé par ce Pattern, regarde du côté du site de Martin Fowler.


L'OCL sert à exprimer des contraintes dans les modèles UML, mais je ne sais pas si c'est vraiment très utilisé dans les faits et s'il y a des outils permettant de transformer les contraintes exprimées dans tes modèles UML, en contraintes vérifiables à l'exécution ???!