объекты в которые маппятся данные о пользователях и сам сервис для их получения

а почему бы не сделать папочку Model/User

у меня например так

и не надо никаких бандлов

просто скажи в чем преимущество делать бандлы вместо папок

так несколько приложений используют UserBundle

так несколько приложений используют UserBundle

эм... тип аля FosUser?

и что значит "несколько приложений"?

например воркер, который берет себе пачку бандлов нужных: RabbitmqBundle, UserBundle -> DBBundle/DoctrineBundle

опиши ситуацию, что за приложения, им нужен функционал 1 в 1?

и ему не нужен Model/News

а соседнее приложение - админка для просмотра юзеров

например воркер, который берет себе пачку бандлов нужных: RabbitmqBundle, UserBundle -> DBBundle/DoctrineBundle

ну так он и не зависит от того что не использует

ей в свою очередь не нужен rabbitmq

Но это одно и то же приложение

одна и та же система

админка на другом сервере крутится

там где воркеры не едят ресурсы

админка на другом сервере крутится

окей, то есть у тебя для каждой такой фигни свой AppKernel?

ну да

а куда еще пихать

не. ты не понял

а

Kernel

AdminKernel, AppKernel, WorkerKernel

не, один

ну только бандлы разные подгружаются

ну тогда ты всеравно все юзаешь)

я об этом говорю

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

в разных репозиториях на разных серваках крутятся

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

а у тебя как ты описал - только один кернел на все

под кернелом что подразумевается?

точка входа в приложение

там где ты бандлы регистрируешь

у меня один AppKernel стандартный симфонийский

но registerBundles у каждого свой

не подключаю в ядро левые бандлы

разные репки же

интересный факт, когда фабьены придумали бандлы, они видели это как "ну чуваку надо разделить приложение - он делает бандлы в src и потом делает разные папки вида app, admin со своими кернелами и т.д.

но не удалось

> но registerBundles у каждого свой то есть у тебя есть несколько GIT репозиториев и общие зависимости ты раскидываешь по ним?

да

то есть в каждом репозитории свой кернел на часть приложения

эм... а зачем?

это ж безумное усложнение

особенно в случае воркеров

чтобы код не тащить лишний с собой

что с того что лишний код просто лежит?

окей

база данных общая?

засоряет контейнер и больше памяти приложение жрет же))

да, бд общая

но разделение на read/write в зависимости от сервиса

тогда тем более не понимаю зачем такие исхищрения

одни воркеры только пишут, им читать не нужно

другие агрегируют

админка и пишет и читает

апи читает

и на каждую фигню по git репе?

ну да

сколько у тебя репозиториев?

в смысле git

сейчас гляну

и сколько подпроектов в шторме открыто постоянно?)

а как за миграциями следите?

16

ERROR: S client not available

omfg

16

сколько людей в команде?

1)

ну 1.5

их тех кто в код ходит

хм...

Кто-то уже заценил новую фичу в сторме? http://i.imgur.com/3250iSj.png

а тебе не сложно ориентироваться в куче репозиториев?

Кто-то уже заценил новую фичу в сторме? http://i.imgur.com/3250iSj.png

так ей же уже пара лет нет?

а тебе не сложно ориентироваться в куче репозиториев?

один раз настроил и все ок

покрытие держу высокое

стараюсь

тесты сами гоняются

в гитлабе

я все понимаю, но общая база..

? серьезно?

из 16 репозиториев не все 16 в бд ходят

из 16 репозиториев не все 16 в бд ходят

скажи просто в чем профит держать 16 репозиториев под один проект вместо 1-ого?

ладно бы у тебя микросервисы и все такое

но нет же

или задумка в том что бы "когда нибудь я разделю базу"

ну смотря как рассматривать термин микросервисы

ну смотря как рассматривать термин микросервисы

если у тебя есть общая база данных - это не микросервисы)

у микросервисной архитектуры нет single point of failure

это основная идея

тогде не микро)

хотя у меня есть CacheBundle, который только в редис ходит

иначе все у кого есть CRON или очереди кричали бы "у нас микросервисы мы крутые"

> хотя у меня есть CacheBundle, который только в редис ходит это кэш, это даже не приложение, это только инфраструктура

у тебя ж там не лежат правила по инвалидации кэша)

ну да, они выше

там где склеивается бд и кэш