DDD — представление Entity DTO в репозиториях

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

Можно ли иметь в моем репозитории DTO, который расширит базовую реализацию объекта, добавив соответствующие поля?


domain-driven-design dto ddd-repositories
person Leonardo    schedule 21.07.2017    source источник
comment
У вас есть эта проблема, потому что вы не отделяете модель записи от модели чтения; в CQRS у вас не будет такой проблемы.   -  person Constantin Galbenu    schedule 21.07.2017

Ответы (1)


arrow_upward
2
arrow_downward

Это совершенно нормально. Пока этот DTO остается в репозитории. В PoEAA Фаулера:

Шаблон репозитория описывается как: выступает посредником между слоями отображения домена и данных, используя интерфейс, подобный набору, для доступа к объектам домена.

Пока репозиторий правильно выполняет свою работу (хранит и извлекает модели предметной области), реализация не имеет значения. Просто убедитесь, что любые детали реализации репозитория не распространяются на остальную часть проекта. Если вы добавляете DTO к своей сущности внутри репозитория, убедитесь, что вы возвращаете сущность без DTO или других не относящихся к делу дополнительных полей.

person Mohamed Bouallegue    schedule 21.07.2017
comment
Осторожно: репозиторий, как описано в цитируемом тексте, не соответствует репозиторию, описанному Эвансом в шестой главе «Дизайн, управляемый доменом». Эванс использует репозиторий между приложением и доменом, а не между доменом и постоянным хранилищем. - person VoiceOfUnreason; 21.07.2017
comment
Я думаю, что Эванс говорит об одном и том же шаблоне репозитория. Можете ли вы объяснить, что означает между приложением и доменом? - person Mohamed Bouallegue; 21.07.2017