plusieurs à plusieurs relation dans ddd

Question

J'ai deux entités Publisher et SocialAccount. SocialAccount contient plusieurs comptes comme Twitter, Facebook, etc.

1 éditeur peut joindre à plusieurs compte social et 1 compte social contient plusieurs éditeurs, ce compte social est également connecté à une autre campagne d'entité. Je veux dire les deux sont des entités indépendantes

Lors de la création de l'instance de l'éditeur, il n'est pas nécessaire qu'il s'abonne à un compte social, il peut s'y abonner à un stade ultérieur.

Je dois abonner l'éditeur à 1 ou plusieurs comptes sociaux. comment puis-je faire

comment puis-je convertir m en relation m en relation de 1 à plusieurs, entre l'éditeur et le compte social. Je ne suis pas sûr parce que j'ai lu dans de nombreux endroits que nous devrions éviter M à M relation entre les entités.

Answer 1

Udi Dahan a un exemple et comment l'éviter: http://www.udidahan.com/2009/01/24/ddd-many-to-many-object-relational-mapping/

Answer 2

Permettez-moi d'sur la réponse de Don, comme je pense qu'il vous mène sur la bonne voie.

Les relations M-to-N sont naturelles, utiles et peuvent être gérées dans DDD. Si vous avez besoin d'une relation M-to-N, vous n'avez pas besoin de la convertir en une (ou plusieurs) relation (s) M-to-1. Udi Dahan's acticle donne un bon exemple de la façon de gérer une relation M-to-N entre entités.

D'abord, déterminez quelle entité doit contenir une liste d'ID de l'autre. Udi utilise l'exemple des offres d'emploi (Job) et des offres d'emploi (JobBoard). Comme un travail peut exister sans tableau de travail et qu'un tableau de travail ne peut pas exister sans travaux, JobBoard est choisi comme racine agrégée et contiendra un List<Job>. Cela peut sembler être une relation M-to-1, mais comme chaque Job peut être dans la liste pour plusieurs JobBoard s, c'est vraiment M-to-N.

Dans votre cas de SocialAccount et Publisher, je recommande quelque chose comme ça en C#:

public class Publisher 
{ 
    public int ID {get; private set;} 

    private readonly IList<int> _AssignedSocialAccounts = new List<int>(); 
    public IEnumerable<int> AssignedSocialAccounts { get { return this._AssignedSocialAccounts; } } 

    public Publisher(int ID) //Pass required fields to the constructor. 
    { 
     this.ID = ID; 
    } 

    public AssignSocialAccount(int SocialAccountID) 
    { 
     if(!this._AssignedSocialAccounts.Contains(SocialAccountID)) 
      this._AssignedSocialAccounts.Add(SocialAccountID); 
    } 
} 

public class SocialAccount 
{ 
    public int ID {get; private set;} 

    public SocialAccount(int ID) //Pass required fields to the constructor. 
    { 
     this.ID = ID; 
    } 
} 

(Cet exemple utilise l'encapsulation de domaine similaire à Jimmy Bogard's Wicked Domain Models.)

Notez que j'ai choisi Publisher être le racine cumulative depuis un SocialAccount peut exister seul, mais un Publisher n'a aucune signification sans l'existence d'un SocialAccount.

Notez également que je passe des ID uniques, pas des références aux objets eux-mêmes. C'est une approche courante dans DDD et permet le chargement paresseux d'entités apparentées, bien que le compromis est que vous devez appeler le référentiel pour obtenir les entités lorsque vous voulez y accéder.

Cette approche signifie également que vous n'avez pas tous les SocialAccount s comme une seule énumération. Ils sont répartis entre les différents Publisher s. Pour obtenir une liste de tous les SocialAccount s nécessitera une requête distincte.