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 revient sans cesse. Lorsque je cherche à la fois sur le Web et sur Stack Overflow pour savoir ce qu'est une racine agrégée, je continue à trouver des discussions à leur sujet et des liens morts vers des pages qui sont 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 d'agrégat 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 en même temps que la racine est chargée ou quand ils sont réellement nécessaires (comme avec le chargement paresseux).

Par exemple, vous pourriez avoir un Orderobjet qui encapsule des opérations sur plusieurs LineItemobjets. Votre code client ne chargerait jamais les LineItemobjets directement, juste celui Orderqui les contient, qui serait la racine agrégée de cette partie de votre domaine.

De Evans DDD:

Un AGRÉGAT est un cluster d'objets associés que nous traitons comme une unité dans le but de modifier les données. Chaque AGRÉGAT a une racine et une frontière. La limite définit ce qui se trouve à l'intérieur de l'agrégat. La racine est une ENTITE unique et spécifique contenue dans AGRÉGAT.

Et:

La racine est le seul membre de AGGREGATE auquel les objets extérieurs sont autorisés à contenir des références à [.]

Cela signifie que les racines agrégées sont les seuls objets qui peuvent être chargés à partir d'un référentiel.

Un exemple est un modèle contenant une Customerentité et une Addressentité. Nous n'aurions jamais accès à une Addressentité directement à partir du modèle car cela n'a pas de sens sans le contexte d'un associé Customer. Nous pourrions donc dire que Customeret Addressformer ensemble un agrégat et c'est Customerune racine agrégée.

La racine agrégée est un nom complexe pour une idée simple.

Idée générale

Un diagramme de classe bien conçu encapsule ses éléments internes. Le point par lequel vous accédez à cette structure est appelé aggregate root.

Les composants 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 classes simple

Comment voulez-vous conduire votre voiture? Choisissez une meilleure API

Option A (cela fonctionne simplement):

car.ride();

Option B (l'utilisateur a accès aux inernals de classe):

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 pouvez manipuler toute la hiérarchie uniquement via l'objet principal.

Imaginez que vous ayez une entité Ordinateur, cette entité ne peut pas non plus vivre sans son entité Logiciel et son entité Matériel. Ceux-ci forment l' Computeragrégat, le mini-écosystème de la partie informatique du domaine.

La racine agrégée 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 d'agrégat comme point d'entrée d'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 possède pas d'identité à lui seul), considérez-le comme un exemple uniquement.

Si vous suivez une approche basée sur la base de données, la racine agrégée est généralement la table du côté 1 d'une relation 1-plusieurs.

L'exemple le plus courant étant 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 plateforme de commerce électronique et nous avons essentiellement deux racines agrégées:

1. Les clients
2. Les vendeurs

Les clients fournissent des informations de contact, nous leur attribuons des transactions, les transactions obtiennent des éléments de ligne, 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 le référentiel client et vendeur respectivement.

Dinah:

Dans le contexte d'un référentiel, la racine agrégée 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.

À partir d'un lien brisé :

Dans un agrégat, il y a une racine d'agrégat. La racine d'agrégat est l'entité parente de toutes les autres entités et objets de valeur au sein de l'agrégat.

Un référentiel fonctionne sur une racine agrégée.

Plus d'informations peuvent également être trouvées ici .

L'agrégat signifie la collecte de quelque chose.
racine est comme le nœud supérieur de l'arbre, d'où nous pouvons accéder à tout comme le <html>nœud dans le document de la page Web.
Blog Analogy, Un utilisateur peut avoir de nombreux articles et chaque article 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 associés et autres commentaires de ces messages. Ce sont tous ensemble dit être collection ou agrégé

L'agrégat est l'endroit où vous protégez vos invariants et forcez la cohérence en limitant son accès à la racine agrégée. N'oubliez pas, l'agrégat doit se baser sur les règles métier et les invariants de votre projet, et non sur la relation avec la base de données. vous ne devez injecter aucun référentiel et aucune requête n'est autorisée.

À 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 la composition OO. Voir un exemple: https://github.com/bryanhunter/cqrs-with-erlang/tree/ndc-london