Qu'est-ce qu'une racine agrégée?
J'essaie de comprendre comment utiliser correctement le modèle de référentiel. Le concept central d'une racine agrégée continue à apparaître. Lorsque je cherche à la fois sur le Web et sur Stack Overflow pour obtenir de l'aide sur ce qu'est une racine agrégée, je continue de rechercher des discussions à leur sujet et des liens morts vers des pages censées contenir des définitions de base.
Dans le contexte du modèle de référentiel, qu'est-ce qu'une racine agrégée?
Dans le contexte du modèle de référentiel, les racines agrégées sont les seuls objets que votre code client charge à partir du référentiel.
Le référentiel encapsule l'accès aux objets enfants. Du point de vue de l'appelant, il les charge automatiquement, soit au moment du chargement de la racine, soit lorsqu'ils sont réellement nécessaires (comme pour le chargement différé).
Par exemple, vous pouvez avoir un objet Order qui encapsule les opérations sur plusieurs objets LineItem. Votre code client ne chargerait jamais les objets LineItem directement, mais bien le Order qui les contient, ce qui constituerait la racine agrégée de cette partie de votre domaine.
De Evans DDD:
Un AGREGAT est un groupe d'objets associés que nous traitons comme une unité dans le but de modifier des données. Chaque AGREGAT a une racine et une limite. La limite définit ce qui est à l’intérieur de l’AGREGAT. La racine est une ENTITÉ unique et spécifique contenue dans l’AGREGAT.
Et:
La racine est le seul membre de AGGREGATE dans lequel les objets extérieurs sont autorisés à contenir des références à [.]
Cela signifie que les racines d'agrégat sont les seuls objets pouvant être chargés à partir d'un référentiel.
Un exemple est un modèle contenant une entité Customer et une entité Address. Nous n’aurions jamais accès à une entité Address directement à partir du modèle car elle n’a aucun sens sans le contexte d’un Customer associé. Nous pourrions donc dire que Customer et Address forment ensemble un agrégat et que Customer est une racine d'agrégat.
La racine agrégée est un nom complexe pour une idée simple.
Idée générale
Le diagramme de classes bien conçu encapsule ses internes. Le point par lequel vous accédez à cette structure s'appelle aggregate root.
Les éléments internes de votre solution peuvent être très compliqués, mais l'utilisateur de cette hiérarchie utilisera simplement root.doSomethingWhichHasBusinessMeaning().
Exemple
Vérifiez cette hiérarchie de classe simple 
Comment voulez-vous conduire votre voiture? Mieux choisir api
Option A (cela fonctionne en quelque sorte):
car.ride();
Option B (l’utilisateur a accès aux classes internes):
if(car.getTires().getUsageLevel()< Car.ACCEPTABLE_TIRE_USAGE)
for (Wheel w: car:getWheels()){
w.spin();
}
}
Si vous pensez que l'option A est meilleure, alors félicitations. Vous obtenez la raison principale derrière aggregate root.
La racine agrégée encapsule plusieurs classes. vous ne pouvez manipuler toute la hiérarchie que via l'objet principal.
Imaginez que vous ayez une entité Ordinateur, cette entité ne peut pas non plus vivre sans ses entités Logiciel et Matériel. Celles-ci forment l'ensemble Computer, le mini-écosystème de la partie Ordinateur du domaine.
La racine d'agrégat est l'entité mère à l'intérieur de l'agrégat (dans notre cas Computer), il est courant que votre référentiel ne fonctionne qu'avec les entités qui sont des racines agrégées et cette entité est responsable de l'initialisation des autres entités.
Considérez la racine agrégée comme un point d'entrée à un agrégat.
En code C #:
public class Computer : IEntity, IAggregateRoot
{
public Hardware Hardware { get; set; }
public Software Software { get; set; }
}
public class Hardware : IEntity { }
public class Software : IValueObject { }
public class Repository<T> : IRepository<T> where T : IAggregateRoot {}
Gardez à l'esprit que le matériel serait probablement aussi un ValueObject (ne pas avoir d'identité par lui-même), considérez-le uniquement à titre d'exemple.
Si vous suivez une approche basée sur la base de données en premier, la racine agrégée est généralement la table située du côté 1 d'une relation à plusieurs.
L’exemple le plus courant est une personne. Chaque personne a plusieurs adresses, un ou plusieurs bulletins de paie, factures, entrées CRM, etc. Ce n'est pas toujours le cas, mais 9/10 fois.
Nous travaillons actuellement sur une plate-forme de commerce électronique, et nous avons essentiellement deux racines globales:
- Les clients
- Les vendeurs
Les clients fournissent des informations de contact, nous leur attribuons des transactions, les transactions obtiennent des postes individuels, etc.
Les vendeurs vendent des produits, ont des contacts, des pages sur nous, des offres spéciales, etc.
Ceux-ci sont pris en charge par les référentiels client et vendeur respectivement.
D'un lien brisé :
Dans un agrégat, il y a une racine agrégée. La racine d'agrégation est l'entité parente de toutes les autres entités et objets de valeur de l'agrégat.
Un référentiel fonctionne sur une racine agrégée.
Plus d'informations peuvent également être trouvées ici .
Dinah:
Dans le contexte d'un référentiel, la racine d'agrégat est une entité sans entité parent. Il contient zéro, une ou plusieurs entités enfants dont l'existence dépend du parent pour son identité. C'est une relation un à plusieurs dans un référentiel. Ces entités enfants sont de simples agrégats.
Agrégat signifie la collecte de quelque chose.
root est comme le nœud supérieur de l’arbre, à partir duquel nous pouvons accéder à tout comme le nœud <html> dans le document de page Web.
Blog Analogie, Un utilisateur peut avoir plusieurs messages et chaque message peut avoir de nombreux commentaires. donc, si nous récupérons un utilisateur, il peut agir en tant que root pour accéder à tous les messages liés et aux commentaires ultérieurs de ces messages. Celles-ci sont toutes ensemble considérées comme des collections ou agrégées
L'agrégat est l'endroit où vous protégez vos invariants et forcez la cohérence en limitant son accès par la racine d'agrégat. N'oubliez pas que l'agrégat doit définir les règles de gestion et les invariants de votre projet, et non la relation avec la base de données. vous ne devez pas injecter de référentiel et aucune requête n'est autorisée.
Dans Erlang, il n'est pas nécessaire de différencier les agrégats, une fois que l'agrégat est composé de structures de données à l'intérieur de l'état, au lieu de OO composition. Voir un exemple: https://github.com/bryanhunter/cqrs-with-erlang/tree/ndc-london