К теме фреймврков - что же лучше - с 0 или на базе ф-ворка.
Беру пример из реального проекта, который я сейчас проектирую.
Для того, что бы проект ен превращался в говно - разделяем его на микросервисы. Своим программистам я даю по одному микросервису на одного-два человека. Это мини-приложение. Изолированное. Со своей БД.
Фреймворк берем Yii2. И сходу добавляем в него некоторые дополнения. Во первых - контракты. Это по сути интерфейсы, если не вдаваться. Я (или другой архитектор) разрабатывает "обязательство", которое программист реализует. Программист реализует сервис. Пока бизнес логика тут, а не в моделях или контроллерах. ПРогарммист четко имплементит контрактные методы.
Контроллера - контроль доступа + запросы. Модель - ORM, реляционная логика. Такие дела. Кроме того, есть стандартизация CRUD. И это по сути самое важное. CRUD - это всё. Что бы там кто не говорил - любые операции можно разбить на CRUD - вопрос на сколько абстрактные и умные у вас компоненты. Т.е. то, что можно сделать автоматизированно - делается автоматизированно. Без хардкода.
На фронтенде - реакт. При том он тоже без хардкода. Он даже не содержит буквально прописанных адресов ендпоинтов API - ему сервер сам это говорит. Так же сервер ему говорит, какой бизнес объект как валидировать и какие действия над каким объектом можно выполнять (поверх CRUD).
Далее, когда программист справился с работой на таком простом фреймворке - усложняем (фрейм - это в основном Yii для старта, потом можно поменять. Да-да! Поменять.).
Усложнение такого плана - начинаем добавлять базовые абстрактные компоненты типа репозиториев, конверторов, object-value и так далее - аля DDD Эванс.
Таким образом переход от простого к сложному. И я могу всё контроллировать. Но фреймворк там есть всегда.
Микросервисы защищают от того, что бы мы получили сильную связанность. Но это радикально. На фронтенде к примеру у нас нет такого разделения - там просто модули. Но в модулях уже можно накакать и связать как то по дибильному.