Create only one bundle called AppBundle for your application logic.
Из
Symfony Best Practices - Creating The Project -
Application Bundles.
But a bundle is meant to be something that can be reused as a stand-alone piece of software. If UserBundle cannot be used "as is" in other Symfony apps, then it shouldn't be its own bundle. Moreover, if InvoiceBundle depends on ProductBundle, then there's no advantage to having two separate bundles.
Грубо говоря, если части логики, которые вы хотите разделить не самодостаточны и не могут быть использованы раздельно - разделять их нет смысла. А вот если вы, например, пишете бандл, который будет использоваться в нескольких проектах - тогда смысл есть.
Хотелось бы логически разбить на бандлы - этот бандл для работы с проектами, этот бандл для работы с пользователями, это для просмотра заданий пользователям и так далее
Я точно не знаю, насколько зависят одни части от других, но в вашем случае, возможно, лучше просто сделать иерархию директорий внутри бандла.
Но все упирается в то, что необходимо тогда обращаться к сущностям в AppBundle, иначе можно насоздавать копий сущностей в разных бандлах одной таблицы(проблема с обновлением БД и повторение кода)
По-моему, вы тут сами не поняли, что написали. Если приведёте пример - будет понятнее.
Но зато бандлы логически отделены, удобно отключать функциональность, обновлять через git и т.д.
А вы будете отключать функциональность так часто? И что не так с git?
P.S. Возникает желание создать отдельный бандл для сущностей, к которой и прописать зависимость всех остальных бандлов
В
некоторых случаях так и делают. Например, у нас есть бандлы сущностей для разных внешних сервисов. Но они сделаны в виде отдельных бандлов, т.к. используются в нескольких проектах и на других проектах часть логики, которая с ними работает на основном, не нужна.
