mardi 24 juillet 2012

RemiDDD Partie II : Aggregate


Lors de la conception d'un projet en utilisant une méthode DDD, on va faire appel à la notion de Aggregate.

Un aggregate est un entité métier de base. Cette entité peut être composée d'autres entités appelées "value object" qui n'ont aucune signification sans leur entité maitre et dont la durée de vie est la même.
Exemple : Un client à une adresse, dans le cadre d'un CRM l'adresse ne veut rien dire sans le client, quand on créera/supprimera un client on créera/supprimera son adresse.

Les Aggregate/value object doivent répondre à ces exigences :
  • Seuls les Aggregates ont un Id
  • Seuls les Aggregates sont filtrables / requêtables (on ne peut obtenir l'Adresse d'un Client sans avoir son Id).
  • Les value object ne peuvent pas référencer d'autres value object, que des Aggregate (l'adresse d'un client pourra référencer un Pays).

Il faut faire attention à ne pas faire des Aggregate sur-dimensionnés embarquants la moitié de la base de donnée.
Prenons l'exemple d'une Commande, on pourrait très bien penser que c'est un value object de Client vu qu'une Commande ne veux rien dire sans le Client. Mais le fait est que dans de nombreuses interfaces on va vouloir éditer les informations de la commande, les filtrer, appliquer une offre spéciale, l'annuler ... On va donc créér un Aggregate "Commande" qui va avoir une référence vers l'Aggregate "Client", les cas d'utilisation ont forcé cette promotion.


Le design des Aggregate se base sur ces cas d'utilisations (d’où leur utilisation en DDD). Lors de leur conception il faut se demander "Est ce que l'on aura besoin de le référencer tout seul quelque part ?" , "Est ce qu'une interface permettra de le mettre à jour ?" ...

Si vous voulez en savoir plus je vous incite à lire les documents écris par Vaughn Vernon : http://dddcommunity.org/library/vernon_2011

Aucun commentaire:

Enregistrer un commentaire