Дизайн, управляемый доменом, и агрегаты

В нашей системе у нас есть база данных, в которой много таблиц с большим количеством столбцов, в некоторых случаях более 300 столбцов. Возьмем пример - автомобиль. У нас есть таблица car, которая содержит 300 столбцов. Помимо идентификатора автомобиля, остальные столбцы содержат данные, связанные с автомобилем fx. размеры правого сиденья.

Вопрос в том, как сопоставить эту таблицу с агрегатом DDD, не загружая все столбцы?

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

Как мы реализуем это способом DDD? Услуги домена?

Мы лаем не на то дерево? Должны ли мы вместо этого использовать CQRS?

Пожалуйста, не обращайте внимания на этот факт; в базе данных бардак.


c# domain-driven-design ddd-repositories
person John    schedule 12.09.2013    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Кажется, ваша проблема в том, что вы сопоставляете совокупность и представление, которое пользователь хочет видеть, 1: 1. Исключительно потому, что мы говорим об агрегате, это не представление 1: 1. (вы сказали это сами, «но в большинстве случаев клиент хочет видеть только небольшую часть совокупности»).

Преимущество использования CQRS (или «только» CQS) заключается в том, что вы можете сосредоточиться на домене, что означает, что вы можете моделировать свои команды и представления (например, запрос) с точки зрения пользователя/клиента, игнорируя текущий дизайн базы данных.

Взгляните на эффективный совокупный дизайн Вона Вернона, возможно, это поможет.

person Khh    schedule 12.09.2013
comment
Если мы посмотрим на сторону записи, как вы, например, обрабатываете команду ChangeNumberOfBoltsCommand? Команда принимает идентификатор автомобиля и количество болтов. Но должен ли репозиторий загружать весь агрегат, чтобы обновить количество болтов? Ленивая загрузка, похоже, противоречит правилам DDD. - person John; 18.09.2013
comment
Это зависит, но, на мой взгляд, весь агрегат должен быть загружен. Я не использую ленивую загрузку, потому что это вызывает проблемы при разработке для домена. - person Khh; 20.09.2013

arrow_upward
0
arrow_downward

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

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

И, конечно же, если вы обнаружите, что инфраструктура постоянства мешает вам моделировать. Вы можете использовать отдельные объекты сохранения. Но это требует больше ресурсов в начале.

С другой стороны, если у вас есть устаревшая база данных, я думаю, сложнее внедрить CQRS. Это может стать слишком большой нагрузкой для вашей команды.

person Yugang Zhou    schedule 12.09.2013

arrow_upward
0
arrow_downward

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

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

Таким образом, DDD и CQRS могут хорошо работать вместе. Существуют также различные уровни CQRS, поэтому вам нужно будет правильно сбалансировать :)

person Eben Roux    schedule 12.09.2013
comment
Вы абсолютно правы, CQRS и DDD не исключают друг друга. Моя ошибка. - person John; 18.09.2013
comment
Мне нравится идея чтения и записи. Чтение просто предоставит ряд DTO с использованием OData или аналогичного. Сторона записи (домен), вероятно, будет использовать DDD. В этом случае мне нужно выяснить, как обрабатывать CRUD-операции на агрегате (Car), который имеет множество свойств. - person John; 18.09.2013