Почему это важно:

1. Архитектурный подход помогает разрабатывать приложение через MVP
2. При разработке монолита у вас формируется единая точка входа
3. При правильном подходе уровень абстракций не должен быть сильно высоким и сильно низким
4. Легко разрабатывать и поддерживать по стандартам SOLID,DRY,KISS
5. Легкость написания документации
6. Простота использования
7. Высокий уровень быстродействия
8. Легкое и понятное модульное тестирование

Что такое архитектурный подход?

Создаем прототип и минимальные требования для системы. 

Важно заложить способность системы к расширению, но не изменению. 
Здесь важно: Дело не в том, что вы не можете физически что-то менять, можно сделать приватный метод публичным и не прописывать read-only(хотя делать это нужно)
Главное, чтобы в дальнейшем не возникало такой необходимости.
В результате мы можем дойти до бесконечного уровня абстракций, чтобы такого не происходило необходимо обозначить границы приложения.
Поэтому прописываем техническое задание на MVP, создаем сущности, роли и связи.

Сущности, роли и связи

Роли должны преобладать над связями и сущностями.
Роли - это не просто статус клиента, это поведение, которое зависит от внешних факторов. Своего рода это DTO относительно поведения приложения на глобальном уровне 
Связи создаются на уровень ниже, здесь как раз и находятся основные контракты.
Важно создать контракты таким образом, чтобы была возможность расширять, но не изменять контракты.

Пример: у вас 3 формата данных и под каждый формат свой класс связанный с контрактом, но некоторые форматы в будущем могут иметь новые методы, для этого методы самих контрактов можно расширить через передачу поведения
Как например способ получения обьекта, через который происходит обработка, тогда всю логику таких меодов вы можете вывести в отдельный модуль и пременить к нему тестирование будет намного проще.
Важно, что при использовании такого подхода он должен быть везде в ващей архитектуре на этом уровне.

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

Что лучше не использовать

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

Что сильно усложняет разработку даже при архитектурном подходе так это синтаксис, перечислим несколько пунктов:
Нежелательно использование альтернативного синтаксиса (через : ?,endif; и т. д.) 
Не используйте  смешанный код (в одном файле css,js,php,html код, это затрудняет поддержку и чтение вашего кода)
По возможности не используйте операторы switch case, особенно в сложных алгоритмах и там где количество проверок больше двух, это усложняет чтение кода.
Не используйте статические методы и классы
Буферизацию желательно не использовать даже на уровне представления
Не используйте метки и прерывания php без веской на то причины.