From many to many relationships in ddd

Question

I have two Publisher objects and SocialAccount. SocialAccount contains several accounts such as Twitter, Facebook, etc.

1 publisher can connect to many social accounts, and 1 social account contains several publishers, this social account is also associated with another organization. I mean, both are independent entities

When creating a publisher instance, it is not necessary that he sign up for a social account, he can subscribe to it at a later stage.

I need to subscribe the publisher to 1 or more social accounts. how i do it

how can I convert the relationship of m to m in 1 to many relationships between the publisher and the social account. I'm not sure, because in many places I read that we should avoid MM relationships between objects.

Answer 1

Udi Dahan has an example of this and how to avoid it: http://www.udidahan.com/2009/01/24/ddd-many-to-many-object-relational-mapping/

Answer 2

Let me tell you about the don, as I think he is leading you on the right path.

M-to-N relationships are natural, useful, and can be handled in DDD. If you need an M-to-N relationship, you don't need to try to convert it to (or most likely several) M-to-1 relationships. The Udi Dahan acticle provides a good example of how to handle M-to-N relationships between objects.

First determine which object should contain the list of identifiers of the other. Udi uses the sample job posting ( Job ) and message board ( JobBoard ). Since a job can exist without employment advice, and a job fee cannot exist without jobs, the JobBoard is selected as the aggregate root and will contain a List<Job> . This may seem like an M-to-1 relationship, but since each Job may be on the list for multiple JobBoard , it really is an M-to-N.

In your case, SocialAccount and Publisher I recommend something like this in 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; } } 

(This example uses domain encapsulation similar to Jimmy Bogard Wicked Domain Models .)

Note that I chose Publisher as the aggregate root, since a SocialAccount may exist on its own, but a Publisher does not make sense without the existence of SocialAccount .

Also note that I'm skipping unique identifiers, not links to the objects themselves. This is a common approach in DDD and allows lazy loading of related objects, although the trade-off is that you need to call the repository to get the objects when you want to access them.

This approach also means that you do not have all SocialAccount as a single listing. They are shared between different Publisher s. To get a list of all SocialAccount will need a separate request.