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

Question

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

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

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

Мне приятно слышать ваши мысли

Answer 1

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

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

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

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

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

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

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