Алексей Скобкин, поддерживаю "архитектурную чистоту".
Только применительно к топику я бы и упростил всё максимально. Иначе, действительно, получится новый Laravel, с кучей огрехов))
Павел Корнилов, только как образец "для понимания".
Однако я против такой реализации в продакшен)
Ибо $_REQUEST['lang'] переданный в require имеет кучу возможностей подгадить в скрипт)
Алексей Скобкин, частично согласен. Но в данном случае, как я вижу устройство приложения, мы имеем дело с God-объектом.
Вся реализация БД уходит в руки PDO. Потому можно было бы сказать, что App и не знает ничего об этом. И опять возвращаюсь к исходному — лишнее усложнение в текущей реализации не нужно.
Anton Kravchenko, выходит, у вас один продукт с разными подставками для разных клиентов.
Тогда полагаю аналогия должны быть такая: ресторан всем делает омлет, только кому-то с помидорами, а кому-то с луком.
Если так, что я бы уделил внимание именно поставке с раздельным блоком, специфичным для клиента.
Можно вообще сделать один репо для ядра (для омлета), а второй и остальные для деталей (для лука, для помидоров).
Тогда, если изменения идут в ядро — то они пушатся всем клиентам.
Если изменения идут в конкретную специфичную интеграцию, то она пушится всем клиентам, которые работают с этой интеграцией.
Только применительно к топику я бы и упростил всё максимально. Иначе, действительно, получится новый Laravel, с кучей огрехов))