Так ты обозначил проблему как "логи все засраты". Формулируй вопрос чётче

думаю это норм держать объекты внутри, но не ок делать что-то типа $aggregate->getTranslations()->first()->setNewValue()
короче не ок отдавать свои внутренности наружу для изменений в других сервисах

Используй либо url либо host,dbname,etc параметры. https://github.com/doctrine/DoctrineBundle/pull/1335

ок
пасип

закон деметры

Добрый вечер. Подскажите курсы по симфони кроме ютуба и отуса, можно платные. На udemy есть за 2018 год, симфони 3. Уже не актуально?

Symfonycasts

Желательно на русском)

м, в программирование идти, надеясь, что всё будет на русском... хороший подход

Курсы от специалист!!!

это же не значит что сначала надо выучить английский а потом уже программирование

хотя я понимаю что желательно)

Крайне необходимо

понял принял

Насколько я помню, где-то здесь уже упоминали, что переводы к домену не имеют отношения. То есть их в бизнес-логике быть не должно по идее

Нельзя однозначно так сказать без хотя бы приблизительного понимания доменной области

есть _легаси_ приложение с применением компонентов, часть software appliance, на ~600 роутов - это в перспективе ~400 реквест парам резолверов если вообще их использовать
если хорошо просушить то м.б. 400 роутов, но количество будет расти т.к. вырастет функционал
какая практика лучше чем разделение по кернелам? в доке пишут "не надо так"
есть возможность выделить хорошо выраженные модули соединяемые через события, стали-бы ради этого насильно вырезать их в отдельные "приложения" и связать через шину?

задайся вопросом какую проблему ты хочешь решить. Пока у тебя эти "отдельные приложения" имеют связанность на уровне базы данных толку от разделения на отдельные приложения нет, а если же эта проблема решена то какие еще проблемы есть?

Тебе нет нужды "разделять" кернелы и т.д. если ты просто хочешь модульность сделать.

Я б переписал на го