Ни один нормальный проект не начинается, не с первого, не со второго. И то и другое, первым номером, приведёт в итоге к проблемам.
Проектирование по пунктам:
1. Анализ бизнес процессов которые протикают в компании и сбор информации.
2. Технических анализ предыдущего пункта и разбитие его на сущности с построением модели.
3. На основе концепции проектируется база данных, и проверяется, что у вас все запросики работают как нужно, и если нужно тестируется на устойчивость и нагрузки, для оптимизаций. Если есть проблемы, возвращаемся к пункту 2, а то и 1.
4. Когда БД, построена, оттестирована и не противоречит модели, пишется бизнес логика.
Между 1 и 2 пуктом может быть еще парачка в зависимости от того, кто и как работает, но в минималке это выглядит вот так.
Это очень хороший подход, но только для человека/команды с очень хорошим уровнем, особенно в проектировании
Чаще всего когда убьют кучу времени на проектирование бд, бизнес логику и.т.д через какое-то время после первых +- рабочих частей приложения резко меняются требования, вплоть до смены части бизнес логики, структуры бд, и тогда начинается беготня туда сюда, с кучей правок на то, что уже казалось бы готово. Но это так, просто к слову
Условные джуны могут все эти пункты пройти, но это может оказаться менее эффективным и более времязатратным чем если начать "сразу думать и пилить"
Но мб я и неправ
