DDD логика и Постоянство Незнание

Question

Рассмотрим следующий сценарий:

public class Document 
{ 
    private ISet<User> sharedWith; 

    public Document(string name) 
    { 
    this.sharedWith = new HashSet<User>(); 
    this.Name = name; 
    } 

    public string Name { get; private set; } 

    public IEnumerable<User> SharedWith 
    { 
    get 
    {  
     return this.sharedWith; 
    } 
    } 

    public void ShareWith(User user) 
    { 
    if (this.SharedWith.Contains(user)) 
    {  
     throw new Exception("This document is already shared with that user."); 
    } 

    this.sharedWith.Add(user); 
    } 
} 

• Documents может использоваться совместно с User
• При совместном использовании документа с пользователем, если документ уже совместно с этим пользователем, выбросить исключение.
• Документы могут использоваться совместно с 10 тысячами пользователей.

Очевидно, что это не очень хорошо масштабируется, из-за необходимости проверки SharedWith для пользователя существования, в результате ОРМ ленив загрузкой всей коллекции в памяти. I может выполнить проверку наличия в службе приложения, но я рассматриваю эту логику домена, и поэтому для меня имеет смысл, что я храню ее в классе Document.

Я не могу понять, как это должно быть сделано с DDD? И что, если я не смогу использовать ORM, как это сделать?

Я предполагаю, что я должен иметь документ Aggregate и пользователя агрегатный?

Я просмотрел различные ресурсы DDD (я еще не читал книгу), но я не могу найти ответ на этот конкретный сценарий.

Answer 1

это было быстро сделано так, что это не идеальный, но вы получите его суть:

public class User { public Guid UserId { get; set; } } 

public class Document 
{ 
    public string Name { get; private set; } 

    private ICollection<User> sharedWith = new List<User>(); 

    private DateTime? publishedOn; 

    public Document(string name) 
    { 
     if (string.IsNullOrWhiteSpace(name)) 
     { 
      throw new ArgumentException("Name is required"); 
     } 

     this.Name = name; 
    } 

    public void Publish() 
    { 
     if (this.publishedOn.HasValue == false) 
     { 
      this.publishedOn = DateTime.UtcNow; 
     } 
    } 

    public void SharedWith(User user) 
    { 
     if (this.publishedOn.HasValue == false) 
     { 
      throw new InvalidOperationException("Document must be published for sharing is allowed."); 
     } 

     sharedWith.Add(user); 
    } 
} 

public interface IDocumentRepository 
{ 
    Document documentOfId(Guid id); 

    bool IsAlreadySharedWith(Guid documentId, Guid userId); 
} 

public interface IUseRepository 
{ 
    User userOfId(Guid id); 
} 

public class ShareDocumentService 
{ 
    private readonly IUseRepository userRepository; 
    private readonly IDocumentRepository documentRepository; 

    public void ShareWith(Guid userId, Guid documentId) 
    { 
     if (documentRepository.IsAlreadySharedWith(documentId, userId)) 
      throw new InvalidOperationException("Document has already been shared with user."); 

     User user = userRepository.userOfId(userId); 

     Document doc = documentRepository.documentOfId(documentId); 

     doc.SharedWith(user); 
    } 
} 

Answer 2

Я полагаю, что если бы вы моделировали это в мире, основанном на бумаге/актере, тогда у кого-то была бы задача сортировки, у кого есть доступ к тому или иному документу (документам), и это, вероятно, будет опираться на какой-то бумажный артефакт. Чтобы получить доступ к документу, вам необходимо заполнить форму запроса документа, которая может пройти процесс утверждения.

Эта форма в мире, основанном на бумаге, станет связующим звеном «многие-ко-многим», который станет ключом к доступу пользователей к защищенным документам. Это сделало бы User, Document и DocumentRequestForm тремя отдельными объектами.