Существует ли распространенный шаблон DDD для недогрузки доменных объектов?
Иногда при работе с приложениями, особенно при попытке следовать правильным шаблонам OOD и DDD, мы в итоге получаем классы домена, такие как Customer, Затем у нас есть репозиторий, который загрузит этот объект, и все хорошо и чисто.
Затем приложение усложняется, и мы начинаем оптимизировать производительность. Мы часто оказываемся в ситуациях, когда нам не нужно загружать, скажем, полный список Customer объекты, но, возможно, только идентификаторы и имена, или небольшое подмножество свойств (например, для отображения в сетке)
Решения, которые я часто видел, включают:
Недостаточная загрузка доменных объектов, поэтому в основном мы все равно будем использовать
Customerкласс, но мы будем использовать отдельный метод хранилища для их загрузки, и этот метод хранилища будет загружать из базы данных только обязательные поля и заполнять соответствующие свойства в объектах. остальнойCustomerполя останутся со своими значениями по умолчанию. Это простое решение, но оно может привести к множеству ошибок, если разработчик (или существующий код) ожидает загрузки определенных свойств.Цель-классификация, где мы создаем такие классы, как
CustomerIdName,CustomerInfo,CustomerHeaderкоторые содержат только те свойства, которые нам нужны. Такой подход может создать большое количество классов, но при тщательном создании подклассов это выполнимо. Похоже, что это отнимает от вездесущей концепции доменного языка.
Так есть ли какое-то общепризнанное соглашение, чтобы справиться с ними в мире DDD? Я пытался гуглить это, но не смог найти ничего авторитетного.
Или, может быть, это просто известное ограничение классического подхода DDD, и CQRS или другие подходы были бы лучше в этих сценариях?
4 ответа
Я думаю, что второй подход - это путь. Мы делаем это в наших проектах, но только для чтения классов DTO. Пока вы не используете их для вставки / обновления, это просто отлично, я думаю.
Также есть ответ, который вас может заинтересовать:
Это хорошо известное ограничение DDD, а CQRS - очень хороший подход для его решения.
CQRS на стороне чтения - это в основном решение № 2 со всеми необходимыми мерами предосторожности, чтобы не путать модели чтения с изменяемыми объектами домена: для них нет репозитариев, классы только для чтения и т. Д.
Вы смотрели в Entity Framework? Они имеют несколько уровней ленивой загрузки сущности: MSDN Post
Я не понимаю, почему под нагрузкой может быть проблема. Вы знаете, какие поля являются недопустимыми, поэтому можете заблокировать доступ / лениво загрузить их