Как обрабатывать свойства, существующие между сущностями (в данном случае в отношениях «многие ко многим»)?

Я нашел несколько вопросов о моделировании отношений «многие ко многим», но ничего, что помогло бы мне решить мою текущую проблему.

Сценарий

Я моделирую домен с Users и Challenges. У задач много пользователей, а пользователи принадлежат многим задачам. Проблемы существуют, даже если у них нет пользователей.

введите здесь описание изображения

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

Вопрос

Какую схему следует использовать, если я хочу запросить индивидуальный рейтинг пользователя в вызове (без получения рейтинга всех пользователей в вызове)? На данном этапе мне все равно, как я делаю вызов доступа к данным, я просто не хочу возвращать сотни точек данных ранга, когда мне нужна только одна.

Я также хочу знать, где хранить информацию о рейтинге; такое ощущение, что это зависит как от пользователя, так и от задачи. Вот что я рассмотрел:

  1. Очевидное: при создании экземпляра Challenge просто получить всю информацию о ранге; медленнее, но работает.

  2. Создайте составной UserChallenge объект, но это похоже на нарушение домена (мы не говорим о проблемах пользователей).

    введите здесь описание изображения

  3. Третий вариант?

Я хочу пойти с номером два, но я недостаточно уверен, чтобы знать, действительно ли это подход DDD.

Обновлять

Я полагаю, я мог бы назвать UserChallenge как-то более подходящим для домена, например, Rank, UserRank или что-то в этом роде?


many-to-many domain-driven-design ddd-repositories domain-model
person Matt    schedule 04.05.2012    source источник
comment
+1 за красивую графику UML, какой инструмент вы использовали для их создания?   -  person Matt    schedule 04.05.2012
comment
yuml.me — чертовски круто. Обнаружил это сегодня точно так же, как и вы.   -  person Matt    schedule 05.05.2012

Ответы (2)


arrow_upward
1
arrow_downward

Подход DDD здесь будет состоять в том, чтобы рассуждать с точки зрения предметной области и обсуждать этот конкретный вопрос со своим экспертом по предметной области/бизнес-аналитиком/кто угодно, чтобы уточнить модель. Не забывайте, что имена ваших сущностей являются частью вездесущего языка и должны быть поняты и использоваться нетехническими людьми, поэтому, возможно, «UserChallenge» здесь не самый подходящий термин.

Сначала я попытаюсь определить, заслуживает ли этот «средний объект» место в модели предметной области и вездесущем языке. Например, если вы создаете веб-сайт и у вас есть специальная страница рейтингов, на которой пользователь может увидеть список всех своих испытаний с соответствующими рейтингами, скорее всего, рейтинги являются ключевым вопросом в приложении, и рейтинг< /strong> сущность будет хорошим выбором для представления этого. Вы можете поговорить со своим экспертом по домену, чтобы узнать, подходит ли ему название «Рейтинги», или выбрать другое имя.

С другой стороны, если нет доказательств того, что такая сущность необходима, я бы придерживался варианта 1. Если вас беспокоят проблемы с производительностью, есть способы уменьшить множественность отношений. Эрик Эванс называет это уточняющей ассоциацией (DDD, стр. 83–84). С технической точки зрения, это может означать, что в Challenge есть карта или словарь рангов с пользователем в качестве ключа.

person guillaume31    schedule 08.05.2012
comment
Немного подумав, я пришел к аналогичному выводу: мне нужна сущность Rank или Ranking. Это показалось мне наиболее подходящим, когда я понял, что у пользователя есть ранг. Это привело к тому, что у пользователя была Rank коллекция словарей с вызовом в качестве ключа. - person Matt; 08.05.2012

arrow_upward
0
arrow_downward

Я бы выбрал вариант 2. Вам не нужно «рассуждать о проблемах пользователей», но вам нужно собирать всех пользователей для данной задачи и сортировать их по рангу, и эта модель дает вам отличный способ сделать это!

person lbstr    schedule 04.05.2012