Дизайн, управляемый доменом, как мне работать с данными пользователя? - PullRequest
0 голосов
/ 08 октября 2018

Прочитав DDD Эрика Эванса, я пытаюсь применить его к проекту, которым управляю.Есть некоторые пользовательские данные запроса, и я не совсем уверен, как реализовать это в DDD.

Например, если пользователь запрашивает уведомления, приложение должно сообщить пользователю, читается ли каждое сообщение или нет.Обычно в таких ситуациях я отвечал бы данными, которые выглядят следующим образом:

{
    "notices": [
        {"content": "foo", "is_read": true}, 
        {"content": "bar", "is_read": false}
    ]
}

Предположим, что существует Notice сущность и Read сущность, которая сохраняет, если User прочитал ее.Также предположим, что есть очень много пользователей, читающих уведомление, что поиск всех пользователей для is_read не является эффективным способом.

  • Поскольку сущность Read никогда не запрашивается без сущности Notice, я мог бы поместить ее в совокупность Notice.Затем реализуйте функцию запроса, принимая запрашивающего пользователя в качестве параметра.

  • Или я мог бы разделить NoticeRepository и ReadRepository, запросить уведомления, а затем объединить их на прикладном уровне с чтениями, запрашиваемыми с идентификаторами уведомлений.

Первый вариант, по-видимому, предполагает, что пользователь запрашивает уведомления и портит уровень домена с помощью логики приложения.С другой стороны, второй вариант дает мне ощущение, что я реализую простую функцию излишне сложным способом.И я не могу сейчас придумать другие варианты .. Что может быть лучшей практикой для такого случая?

Ответы [ 3 ]

0 голосов
/ 09 октября 2018

Все это нужно сделать в Query Service,

Книга Эрика Эванса - хорошая основа, и теперь она перешла к более современным шаблонам, например, CQRS в книге Вона Вернона «Внедрение на основе домена»Дизайн (IDDD).

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

Возможно, вы посмотрите на какой-нибудь примерслужбы запросов (написано в Java) здесь:

https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_collaboration/src/main/java/com/saasovation/collaboration/application/forum/ForumQueryService.java

https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_collaboration/src/main/java/com/saasovation/collaboration/application/forum/DiscussionQueryService.java

0 голосов
/ 10 октября 2018

У меня не было бы объекта Read.Просто обратите внимание и пользователь.В разделе «Пользователь» у вас будет список идентификаторов уведомлений, которые прочитал пользователь (или наоборот), в разделе «Уведомление» у вас будет список идентификаторов пользователей, прочитавших уведомление).

Затем, чтобы запросить информацию, которую вынужно показать в пользовательском интерфейсе, у вас есть несколько альтернатив, как говорит Вон Вернон в своей книге «Внедрение DDD» (стр. 512):

  • DTO

  • Посредник

  • Объект полезной нагрузки домена

  • Представления состояний

  • Варианты использования в оптимальных запросах репозитория (закрыто для CQRS)

  • Трансформаторы данных

0 голосов
/ 08 октября 2018

Я не могу сейчас думать о других вариантах

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

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

Таким образом, создаваемое представление будет выглядеть примерно как список активных уведомлений, оставленных присоединенными к подтверждениям от Боба.

Другая вещь, которая может вас пересечьявляется то, что попытка сделать соединения "вручную", используя хранилища для извлечения данных, является настоящим препятствием.Кроме того, то, что люди осознали за годы, прошедшие с момента написания синей книги, может и не понадобиться.Поскольку запросы безопасны , они не изменяют базовые данные - и если базовые данные не собираются изменяться, нам действительно не нужна модель домена для защитыбизнес-инвариант.

...