То, что Эрик Эванс (автор оригинальной книги DDD) подразумевал под «создать иллюзию коллекции в памяти», я думаю, больше похоже на «обработка общего поиска данных и проблем/механизмов управления от имени домена». объекты модели, чтобы код предметной области не был засорен этим материалом», а не «притворяться, что удаленной базы данных нет». Потому что вы хотите, чтобы ваш предметный объект был сфокусирован на захвате бизнес-правил. Речь идет о том, чтобы модель предметной области оставалась работоспособной и чистой, простой для понимания и аргументации, но в то же время вы не можете игнорировать тот факт, что вы делаете нелокальный вызов вне процесса - вы должны сбалансировать из двух.
P.S. Что касается «семантики стиля коллекции» - это один из способов сделать это, но вы также можете организовать семантику вокруг конкретных сценариев использования (то, что Роберт Мартин назвал бы вариантами использования). У вас может быть несколько репозиториев в вашем приложении, поддерживаемых одной и той же БД, это не обязательно должен быть один большой объект Бога. DDD на самом деле не предписывает все эти (тактические) шаблоны, которые люди с ним ассоциируют, он просто дает их в качестве примера того, из чего вы можете построить свою систему. DDD рассказывает о том, как подходить к моделированию, как выяснить, что вам действительно нужно создать, и как согласовать ваше представление о предметной области (ваша концептуальная модель предметной области) с реальными потребностями предметной области реального мира. DDD развивает это, среди прочего, с точки зрения ряда стратегических паттернов высокого уровня. Пока вы делаете это, вы можете использовать совершенно другой набор тактических схем, это все равно будет DDD.
Рекомендую посмотреть эти видео для лучшего погружения в вопрос: