Илья Зябиров

PHP для подобной задачи - неподходящий инструмент. Готов предположить, что выбор пал на него в связи с тем, что вы хотите написать полноценное приложение, в котором ваша ML-модель будет использоваться.

Я бы посоветовал саму модель сделать на Python и написать для нее простейшее API, через которое можно было бы запрашивать данные и использовать их в вашем PHP-приложении

Можно действительно разделить приложение на бандлы, хотя разработчики Symfony не рекомендуют такую структуру проекта, начиная с 4 версии.

Лично я бы сделал разделение по доменному слою: для каждой сущности выделял бы по сервису + репозиторию. А контроллеры бы разграничил просто по уровню доступа, а шаблоны - по папкам. Миграции бы оставил в одном месте в том случае, если БД у вас одна: в противном случае это имеет мало смысла

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

У вас маппинги уже настроены таким образом, что вы можете просто достать нужный город и через геттер получить коллекцию сервисов, которые в нем есть - доктрина все сделает за вас.

Что касается запроса, он не совсем корректен. Во-первых, вы подставляете параметр не туда, куда необходимо: последний параметр в innerJoin'е отвечает за то, по какому параметру соединять две сущности. Во-вторых, вы обращаетесь к city_id при том, что делаете запрос не на SQL, а на DQL - то есть по сути во время выполнения этого запроса вы присоединяете не таблицу, а коллекцию объектов. На этом уровне доктрина не в курсе ни о каком city_id. В-третьих, доктрина при присоединении коллекции понимает, что речь идет о many-to-many - соответственно, последние два параметра при join'е можно опустить:

->join('service.cities', 'city')
->andWhere('city.id = :id')
->setParameter('id', $id)

Работая с доктриной, следует немного поменять мышление: стоит абстрагироваться от бд и думать о сущностях как об обычных объектах. Надеюсь, что мне удалось корректно сформулировать ответ.

Если у Вас API + отдельный фронт - то мало смысла явно передавать на фронт разрешения. Вам достаточно будет при запросе ресурса получать текущего пользователя по токену, проверять его права и отдавать 403 (или 401, если пользователь не предоставил токен вовсе), если их недостаточно для доступа к ресурсу.
В свою очередь на фронте Вы будете обрабатывать код ответа и выводить на экран то, что нужно.