Как решить проблемы производительности / памяти, связанные с наличием объектов, которые зависят от других объектов в DDD?

Question

Предполагая, что я не использую ORM, и следуя DDD, рассмотрим следующий случай:

A Project имеет набор File s.

Я создали классы Project, и ProjectRepository, и классы File, и FileRepository.

Моя первоначальная идея заключалась в том, чтобы все объекты File для данного Project передавались ему вего конструктор.Этот экземпляр Project, конечно, будет создан с помощью ProjectRepository.

Проблема в том, что если у меня будет миллион файлов (и хотя у меня не будет миллиона файлов, у меня будет достаточночтобы это заняло некоторое время), мне придется загрузить их все, даже если они мне действительно не нужны.

Какой стандартный подход к этому?Я не могу придумать ничего лучше, чем передать FileRepository каждому Project экземпляру.

Answer 1

Поскольку вы упоминаете DDD: если есть два репозитория, это означает, что есть два Совокупных корня .Весь смысл концепции Aggregate Root заключается в том, что каждый корень отвечает за свой весь граф объектов .

Если вы попытаетесь смешать файлы в граф объектов Project, то владение файламинеоднозначно.Другими словами, не делайте этого:

project
- file
- file
- file

Либо обращайтесь с ними как с двумя (связанными) графами объектов, либо переделайте API так, чтобы был только один Aggregate Root (хранилище).

Answer 2

Стандартного способа не существует. Это дизайн, управляемый доменом, поэтому, если вы спросите, это зависит от домена. Может быть, вы могли бы добавить еще один домен в свой дизайн. У вас есть только две концепции: проект и файл. Но вы говорите, что не хотите загружать файл (при условии, что File всегда загружает содержимое файла).

Так что, возможно, вам следует подумать о FileReference, который представляет собой упрощенное представление файла (имя, путь, размер?). Для меня это звучит так, будто ваша проблема в обработке большого набора файлов, а не в ООП.

Answer 3

Вы можете реализовать сервисный уровень , с которым взаимодействуют ваши клиенты, который координирует работу репозиториев и возвращает доменные объекты.Это обеспечило бы лучшее разделение интересов;Лично я не думаю, что ваш клиент должен иметь доступ к вашим репозиториям.