от многих до многих отношений в ddd

Question

У меня есть два объекта Publisher и SocialAccount. SocialAccount содержит несколько учетных записей, таких как Twitter, Facebook и т. Д.

1 издатель может подключаться ко многим социальным аккаунтам, а 1 социальная учетная запись содержит несколько издателей, эта социальная учетная запись также связана с другой организацией. Я имею в виду, что оба являются независимыми объектами

При создании экземпляра издателя необязательно, чтобы он подписался на социальную учетную запись, он может подписаться на него на более позднем этапе.

Мне нужно подписаться издателем на 1 или несколько социальных аккаунтов. как это сделать

как можно преобразовать отношения m в m в отношения 1 к многим, между издателем и социальной учетной записью. Я не уверен, потому что во многих местах я читал, что мы должны избегать отношений M-M между сущностями.

Answer 1

Уди Даан есть пример этого, и как избежать его: http://www.udidahan.com/2009/01/24/ddd-many-to-many-object-relational-mapping/

Answer 2

Позвольте мне расширить ответ Дона, как я думаю, что он ведет вас на верном пути.

Отношения M-to-N являются естественными, полезными и могут обрабатываться в DDD. Если вам требуется отношение M-to-N, вам не нужно пытаться преобразовать его в (или, скорее всего, несколько) отношений M-to-1. Udi Dahan's acticle дает хороший пример того, как обрабатывать отношения M-to-N между объектами.

Сначала определите, какой объект должен содержать список идентификаторов другого. Udi использует пример сообщений о вакансиях (Job) и доски объявлений (JobBoard). Поскольку работа может существовать без совета по трудоустройству, и плата за работу не может существовать без заданий, JobBoard выбирается как совокупный корень и будет содержать List<Job>. Это может показаться отношением M-to-1, но поскольку каждый Job может быть в списке для нескольких JobBoard s, это действительно M-to-N.

В вашем случае SocialAccount и Publisher, я рекомендую что-то вроде этого в 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; 
    } 
} 

(В этом примере используется домен инкапсуляция, похожая на Jimmy Bogard's Wicked Domain Models.)

Обратите внимание, что я выбрал Publisher быть совокупный корень, так как SocialAccount может существовать сам по себе, но Publisher не имеет смысла без существования SocialAccount.

Также обратите внимание, что я пропускаю уникальные идентификаторы, а не ссылки на сами объекты. Это общий подход в DDD и допускает ленивую загрузку связанных объектов, хотя компромисс заключается в том, что вам нужно вызвать репозиторий для получения объектов, когда вы хотите получить к ним доступ.

Этот подход также означает, что у вас нет всех SocialAccount s как единственное перечисление. Они разделены между различными Publisher с. Для получения списка всех SocialAccount s потребуется отдельный запрос.