DDD - объект домена (aggreagate) с большой коллекцией другого субъекта

Question

В приведенном ниже сценарии

class Group { 
    ... 
    Set<User> users; 
    ... 
} 

, где число пользователей в 6-ти цифр, то можно с уверенностью предположить, что выполнение какой-либо операции по коллекции Неэффективное прямое использование любого ORM (JPA/Hibernate в Java, возможно, может быть обработано с помощью ExtraLazyCollection спящего режима).

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

class Group { 

    User addUser(User anUser, GroupUserService aGroupUserService){ ... } 
    void removeUser(User anUser, GroupUserService aGroupUserService){ ... } 
} 

class GroupUserService { 

    GroupRepository groupRepository; 

    User addUser(User anUser) { 
     groupRepository.addUser(anUser); 
    } 
} 

class GroupRepository { 

    User addUser(User anUser) { 
     //execute the query(JQL or native) to save the user 
    } 
} 

делает этот звук как разумное решение, не нарушая принципы DDD, есть оптимизация, которая в настоящее время по-смотрел в этом случае.

Answer 1

Кажется, у вас может отсутствовать концепция GroupMember.

GroupMember member = group.addUser(user); 
groupMemberRepository.add(member); 

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

Хотя верно, что бизнес-правило не может применяться в домене, вы можете просто полагаться на уникальное ограничение в базе данных (при условии, что механизм хранения поддерживает их).

Это компромисс, который мы можем сделать, чтобы быть последовательным и оставаться практичным, а не быть пуристом.

Однако есть и другая альтернатива, но для этого потребуется углубленный анализ бизнеса. Мы часто склонны рассматривать бизнес-правила как математические модели, но реальная жизнь часто не может быть смоделирована как таковая.

Каковы риски и последствия дублирования членства? Может ли это быть просто идентифицировано и исправлено вручную? Может ли это правило быть в конечном итоге последовательным (автоматизированный процесс избавляется от дубликатов)? Как часто это могло произойти?

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