Иногда при работе с приложениями, особенно при попытке следовать правильным шаблонам OOD и DDD, мы получаем классы предметной области, такие как Customer. Затем у нас есть какой-то репозиторий, который будет загружать этот объект, и все красиво и чисто.
Затем приложение усложняется, и мы начинаем оптимизировать производительность. Мы часто оказываемся в ситуациях, когда нам действительно не нужно загружать, скажем, список полных Customer объектов, а может быть только идентификаторы и имена, или небольшое подмножество свойств (например, для отображения в сетке)
Решения, которые я часто видел, включают:
Недостаточная загрузка объектов домена, поэтому в основном мы по-прежнему будем использовать класс
Customer, но мы будем использовать отдельный метод репозитория для их загрузки, и этот метод репозитория будет загружать из базы данных только необходимые поля и заполнять соответствующие свойства в объекты. ОставшиесяCustomerполя останутся со значениями по умолчанию. Это простое решение, но оно может привести ко многим ошибкам, если разработчик (или существующий код) ожидает загрузки определенных свойств.Целевое классирование, когда мы создаем такие классы, как
CustomerIdName,CustomerInfo,CustomerHeader, содержащие только те свойства, которые нам нужны. Этот подход может создать большое количество классов, но при тщательном создании подклассов это работает. Однако кажется, что это отвлекает от повсеместной концепции доменного языка.
Итак, существует ли какое-то общепринятое соглашение для работы с ними в мире DDD? Я пытался найти это в Google, но не смог найти ничего авторитетного.
Или, может быть, это просто известное ограничение классического подхода DDD, и CQRS или другие подходы были бы лучше в этих сценариях?
