В PHP сообществе вообще не развиты вопросы проектирования и архитектуры. Большинство лепит, что придумает. PHP изначально родился для примитивных homepage, вобрал в себя всю несерьезность, низкий порог входа и как следствие довольно слабое комьюнити, что часто становится объектом для шуток.
Искать ответы на вопросы проектирования и архитектуры нужно в Java. Например там почти каждый с самых азов слышал о де факто ставшей стандартом слоистой архитектуре, она же layered architecture, она же n-tier architecture и видел изображение похожее на это
Из которой нужно понять, что всю программу можно разделить на несколько слоев и зависимость между слоями должна быть направлена сверху вниз, но не наоборот. Таким образом, например фреймворк может быть инкапсулирован в presentation слой и в любой момент безболезненно заменен на другой, так как другие слои ничего о нем не знают. Вся бизнес-логика инкапсулирована в domain слой в виде plain old java object, который не зависит вообще не от чего, а также предоставляет интерфейсы (репозиториев например) для инфраструктурного слоя и только в этом слое фактически и будет тот самый настоящий ООП, который все так упорно пытаются найти. Никакого стороннего кода в бизнес-логике нет, а соответственно весь сторонний код можно в любой момент поменять, не трогая бизнес-логику вообще.
Для этого нужно открыть какую-нибудь книгу, где за руку проведут с нуля до конкретного приложения построенного с использованием этой архитектуры. Например
Implementing domain-driven design, хоть эта книга и о DDD, но я уже говорил, что слоистая архитектура это де факто. С опытом, будет понятно, что в более простых приложениях количество слоев можно уменьшить, понимая на какой компромисс придется пойти, что иногда можно объединить domain и часть infrastructure и получить всем известный шаблон Active Record или вообще выбросить эти слои и получить шаблон transaction script, когда для решения просто не требуется что-то более сложное. Придет понимание, как можно начать с transaction script и в итоге постепенно катиться в сторону domain layer, через active record или не через active record если это когда-нибудь понадобится и тому подобное. Cтанет понятно, зачем, как и когда использовать патерны о которых написал Мартин Фаулер в своей книге
Patterns of Enterprise Application Architecture.
Полученные знания можно применить к любому языку. В том числе и PHP. Будет хорошо, если уровень этого сообщества хоть чуть-чуть будет подтягиваться к уровню Java, вместо того чтобы бомбить пятиуровневые ифы создавая такую цикломатическую сложность, что все метрики кода горят ярче красного.