Problème d'agrégat racine dans la conception pilotée par domaine

Question

J'ai deux Entities Publisher et SocialAccount, les deux sont indépendants et ayant une relation de Many à Many. Les deux sont des agrégats racine, maintenant je ne peux pas obtenir de compte social à travers Publisher et je veux convertir M à M relation à 1 à M. Donc, j'ai introduit une autre entité Inscription, aura {PubID, SocID, CreateDate}. Il y a maintenant une relation 1 To M entre Publisher et Registration et 1 à 1 entre Registration et SocialAccount. si l'éditeur aura

Liste <Inscriptions> _Registrations {get; ensemble;}

Mais quand je crée des limites globales, Publisher est ma racine et selon le principe global, seul agrégat racine tiendra référence à un autre agrégat racine. Mais ici, l'inscription contient une référence. Donc, est-ce que je viole le principe de l'agrégat, parce que l'enregistrement est une entité de compte social connecté.

Answer 1

Votre utilisation du concept d'agrégat semble incorrecte. Les objets dans un agrégat peuvent en fait contenir des références à d'autres agrégats. La règle est un objet externe ne peut pas contenir une référence à quelque chose dans un agrégat.

Sur l'objet Enregistrement, vous semblez l'avoir créé pour éviter certaines relations d'agrégation et d'agrégation. Ce n'est pas pour cela que vous créez un objet. S'il y a en fait un enregistrement dans votre domaine, créez-le et modélisez-le. Si ce n'est pas dans votre domaine, ne l'ajoutez pas juste pour traverser un chemin.

Après avoir ajouté l'enregistrement, vous indiquez qu'il ne peut pas contenir de référence au compte social car il fait partie de l'éditeur. Ce n'est pas la règle, mais plus important, comment l'enregistrement est-il soudain devenu une partie de l'agrégat de l'éditeur? En vertu seulement de l'éditeur ayant une collection d'inscription? Un agrégat est un groupe d'objets traités comme une unité pour maintenir l'état et les invariants. L'existence d'une relation par elle-même ne confère pas l'appartenance à un agrégat.

Mais regardez de l'autre côté maintenant. L'inscription est de 1 à 1 avec un compte social. Et si nous supprimons un compte social, est-il toujours logique d'avoir toujours une inscription auprès d'un éditeur? Si ce n'est pas le cas, l'enregistrement fait probablement partie de l'agrégat SocialAccount à la place. C'est pourquoi nous créons des agrégats - pour garantir que les objets et leurs relations sont toujours valides après un changement d'état. Si le changement d'état de suppression d'un compte social inclut la suppression de toutes les inscriptions associées à ce compte, nous souhaitons l'inclure dans l'agrégat pour appliquer cette règle.

Maintenant, vous avez violé la "règle d'agrégation" - vous avez une relation externe de l'éditeur vers un objet, Enregistrement, qui est une partie interne de l'agrégat Compte social.

Ces concepts sont plus que de simples règles, ils ont des raisons. Vous devez revoir ce que les agrégats signifient vraiment, comprendre ce que les règles disent réellement et ce qu'elles signifient réellement, pourquoi elles existent en premier lieu. Réévaluez ensuite vos relations et regroupez les définitions en conséquence.

Answer 2

D'abord, nous avons besoin d'une abstraction pour encapsuler des références dans le modèle. Un AGREGAT est un groupe d'objets associés que nous traitons comme une unité aux fins de modifications de données.

Chaque AGRÉGAT possède une racine et une limite.La frontière définit ce qui se trouve dans l'AGGREGATE. La racine est une ENTITE unique et spécifique contenue dans AGGREGATE. La racine est le seul membre de l'AGGREGATE auquel les objets extérieurs sont autorisés à contenir des références, bien que les objets dans la limite puissent contenir des références les uns aux autres. Les ENTITÉS autres que la racine ont une identité locale, mais cette identité ne peut être distinguée que dans l'AGRÉGAT, car aucun objet extérieur ne peut jamais le voir hors du contexte de l'ENTITÉ racine.

ce que vous en pensez Ssyphus?