Разработка и агрегация доменов

Question

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

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

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

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

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

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

Answer 1

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

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

Посмотрите на effective aggregate Design by Vaughn Vernon, возможно это поможет.

Answer 2

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

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

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

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

Answer 3

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

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

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