И пост апдейт

symfony.lock надо коммитить, тогда не будет создавать

Я не говорил, что это отображение списка. Это может быть получение списка транзакций для осуществления рефанда или пересчета каких-то метрик и бухгалтерии.
Бизнесс- логика это не только «получил от пользователя данные - обработал - сохранил»
Это ещё и «получил данные - выгреб из базы другие - логически обработал - и сохранил результат»

Так вот во втором случае - хорошо бы выгребать список объектов.

он комичен, а в итоге в пайплайнах создается всеравно

Удали вендор, сделай композер инсталл, знакомить symfony.lock

А зачем тебе переводы в бизнес логике?

Я выше привёл другой пример с транзакциями.

Опиши что за операцию ты сделать хочешь

Вот в докер контейнер я копирую композер и симфони лок и делаю инсталл, а оно создает. Там 3 шага до composer install это как-раз копирование

WORKDIR /app
COPY composer.json /app/composer.json
COPY composer.lock /app/composer.lock
COPY symfony.lock /app/symfony.lock

RUN composer install --no-dev --optimize-autoloader

Тут что-то с настройками странное

Ты сделал что я написал?
У тебя содержимое symfony.lock не соответствует composer.lock.
Удаление парки вендор спровоцирует установку всех пакетов и symfony.lock актуализируется

А ещё эту портянку можно сократить до
COPY composer.json composer.lock symfony.lock .

Можно, то тогда при дебаге будут проблемы. Так чётко кидно на каком моменте инвалидировался кеш

Какие только проблемы люди не выдумывают себе

Сработало.
Это получается всегда когда будет хоть на немного менятся композер лок оно будет генерить мне все папки и конфиги заново?

Вроде при первичной установке пакета. При обновлении не обязательно.

Кароч если записи нет в symfony.lock, то происходит установка рецепта и добавление записи в symfony.lock

аш голова кругом идет читая...

В целом я хочу понять каким образом мне из базы вытащить объект или список объектов (аггрегатов) с его зависимостями , чтобы потом с ним работать и можно ли это сделать без сотни запросов в базу? DDD же подразумевает то, что может быть ситуация, когра у тебя есть какая-то коллекция аггрегатов, которую нужно обработать какой-то бизнесс-логикой.

Если нужен конкретный пример то например есть список подписок (агрегатов) на какой-то условный youtube-premium и у этих подписок есть транзакции (успешные/неуспешные) и каждая из успешных транзакция продлевает подписку на месяц. И потом начинается всякая-разная бизнес-слогика связанная с тем, что нужно продлевать подписку какие-то транзакции не прошли и нужно подписку отменить. где-то пользователь пользовался примиумом и решил перейти на премиум+, но переход произошел неудачно и нужно откатить изменения на старый тариф с восстановлением дат транзакций и т.д. и этой логики может быть очень много...

И все это упирается в то, что тебе из базы нужно получать массив ОБЪЕКТОВ аггрегатов и работать с ними. И я пока не вижу другого пути как получать список Root-классов аггрегата, а потом отдельными запросами получать их зависимости.
Или делать RAWSQL джойны и потом маппить полученный массив колонок  ручками на класс-аггрегата.

подожди ты уже yii3, там обещали DDD из коробки

и не будет у тебя таких вопросов, что там DDD подразумевает ,а что нет