Управляемый доменом дизайн: как получить списки сложных данных

Question

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

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

В моем домене у меня есть оценки (набор вопросов для ответа) и ответы (ответы, которые каждый пользователь предоставил для оценки) на эти оценки. У меня тоже есть действия. Каждое действие представляет собой действие, которое было предпринято с ответом (отправить, одобрить, отклонить и т. Д.). У меня также есть пользователи.

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

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

Answer 1

Звучит так, как будто вы (из-за появления этой трудности) определили проблему с вашей моделью домена. Абстракция, которую вы хотите отобразить в каждом из этих списков, очевидно, не очень хорошо представлена ​​ни в вашей модели предметной области, ни в вашем «вездесущем языке». Решите, что это такое, назовите его и добавьте код в свой репозиторий, чтобы сгенерировать списки этих объектов, независимо от того, оказываются ли они объектами или объектами значений ...

Answer 2

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

Проблема в том, что на данный момент у меня нет никакого способа представить весь этот набор данных с сущностями моего домена.

Неловкое дизайнерское трение, которое ты здесь чувствуешь, - это хорошо. Это подсказка, что вещи не совсем подходят друг другу.