DTO сервисного уровня - большие сложные интерактивные объекты, подобные отчетам

Question

У меня есть объекты Meeting, которые составляют основу системы планирования, из которых gridviews используются для отображения важной информации. Это делается для того, чтобы планировать сотрудников на собрания, и чтобы сотрудники могли видеть, что было запланировано.

Я пытался следовать принципам DDD, но мне трудно понять, что перейти от моего уровня обслуживания к области представления системы. Это связано с тем, что расписание может быть БОЛЬШИМ и фактически состоит из множества различных элементов системы. Например. Имя клиента, адрес, информация о деле, группа и т. Д., Все это необходимо для принятия решения планировщиком собрания.

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

Наш текущий подход заключается в заполнении сплющенного "объекта расписания" из SQL, который состоит из небольших частей различных доменных объектов. Это довольно сложный запрос. Когда изменения внесены, они затем передаются обратно на уровень сервиса, и служба извлекает рассматриваемые доменные объекты и запускает бизнес-методы для доменных объектов, используя информацию из DTO.

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

ОБНОВЛЕНИЕ из-за ответа

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

• Клиент находится в одной группе по умолчанию

• У клиента есть один открытый случай, но много закрытых

• Случаи имеют много встреч

• Встреча имеет много назначенных сотрудников

• У встречи много причин

• Встреча может быть запланирована для разных групп

• Сотрудники могут быть связаны со многими группами.

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

Планировщик может видеть имя клиента, адрес клиента, информацию о деле, MeetingTime, MeetingType, MeetingReasons, запланированные группы (showstrail), назначенных сотрудников (также есть скрытые идентификаторы сотрудников).

Редактируемые поля - это назначенные выпадающие списки сотрудников и запланированная группа.

• Расписание может быть до двухсот строк.
• DTO происходит от WCF, поэтому модель домена доступна выше уровня сервиса, а не ниже.
• Бизнес-вызовы модели предметной области, использующиеся сервисом, основаны на значениях DTO, передаваемых обратно, а репозитории работают со вставками / обновлениями.

Итак, я полагаю, для обновления, используется ли запрос для заполнения объекта, который содержит все вышеперечисленное, приемлемо для передачи в виде одного объединенного DTO? А если нет, как бы вы подошли к этому? (приведем несколько примеров обращений к уровню обслуживания и объясним немного о том, как вы представляете себе ORM, извлекающий данные с учетом производительности)

Answer 1

На уровне сервиса и ниже я бы рассматривал каждую сущность (см. Корни агрегатов в DDD) отдельно в отношении ее транзакционной границы. Т.е. даже если бы вы могли обновить клиент и случай в одном и том же представлении пользовательского интерфейса, было бы лучше изменить клиентом транзакцию, а затем изменить случай. Чем больше вы пытаетесь изменить в одной транзакции, тем больше вы можете конфликтовать с другими пользователями.

Несмотря на то, что ваш график большой и может содержать много объектов, сервисный уровень должен снова иметь дело с каждой сущностью (совокупным корнем) отдельно, а затем связать их вместе в новую модель представления. К сожалению, в проектах "коричневого поля" в SQL может быть много логики, а массивные объединения с несколькими таблицами затрудняют рефакторинг в более атомарные запросы, выполняющие именно то, что нужно. Старо-школьное ориентированное на данные представление "делай все, что можно в базе данных" идет вразрез со всем DDD.

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

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

По моему личному мнению, у ориентированных на данные нормализованных приложений данных был свой день (они имели смысл в 1970-х годах, когда место на жестком диске было дорого), и все приложения должны переходить на более современные методы. В действительности, только когда устаревшие системы ползут на коленях, заинтересованные стороны обычно вкладывают деньги в поиск альтернатив (обычно после заполнения каждого последнего сервера оперативной памятью). Возможно, было бы лучше или лучше убедить их в необходимости рефакторинга небольших разделов за раз.