DDD: Следует ли нам иногда обходить доменные модели?

Я работаю над проектом, в котором мы стараемся применить DDD, насколько нам известно. Мы также используем CQRS и луковичную архитектуру. У нас есть агрегаты, для которых есть репозитории. Для каждого поста мы используем заводскую службу, а затем сохраняем результат, используя совокупный репозиторий, для put мы вызываем репозиторий, конечно, без использования фабрики. Все идет нормально!

Здесь для меня это что-то подозрительное, но мне любопытно услышать другие мнения: Для некоторых пользователей вместо использования моделей предметной области из-за проблем с производительностью мы не хотим загружать весь агрегат только для того, чтобы получить 5 полей. Например, мы обходим модели предметной области и используем отдельный репозиторий только для этого запроса CQRS. Этот репозиторий (мы называем его поисковой системой) возвращает DTO (а не модель предметной области, как возвращают обычные репозитории). Мы обходим весь домен, и все происходит на уровне приложений.

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

Мне любопытно услышать твои мысли


clean-architecture cqrs domain-driven-design ddd-repositories
person ClaudiuSocaci    schedule 03.07.2019    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

Исторически, когда Эванс описывает шаблоны реализации, «база данных» - это просто некоторая деталь реализации, скрывающаяся за абстракцией репозитория. Таким образом, доступ к данным ограничен тем, что предоставляется интерфейсом репозитория; это означало совокупные корни или совокупность совокупных корней.

Вы можете увидеть это в Пример Cargo Booking, где репозиторий предоставляет список совокупных корней, а затем этот список корней преобразуется в список DTO.

Я связываю это с тем, что Эванс работал над Java примерно в 2003 году; есть куча подразумеваемых ограничений, которые не имеют более реального оправдания, чем «так мы думали, что хороший объектно-ориентированный дизайн выглядел в то время».

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

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

Единственной обязанностью модели предметной области становится управление изменениями информации, хранящейся в базе данных.

person VoiceOfUnreason    schedule 03.07.2019
comment
Спасибо! Это имеет смысл - person ClaudiuSocaci; 06.07.2019