dumbo101

Если по теории, то мне в свое время вот эта книга помогла:
https://www.litres.ru/robert-s-martin/chistaya-arh...

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

Через несколько месяцев прочел еще раз, анализируя все затупы, что записал за это время в блокнот. После прочтения начал потихоньку рефакторить в существующих проектах места, которые уж очень жить мешали.

Еще через пол года прочел третий раз, опять же с оглядкой на личный опыт. И тут я кажется уже совсем въехал. По крайней мере многие проблемы с организацией взаимодействия между компонентами стали разрешаться. И вообще появилось достаточно четкое понимание, как структурировать приложение и где разбивать его на компоненты.
Ну и после 3 прочтения еще помог момент: мне дали с нуля проектировать новое, достаточно крупное приложение на Rust. Притом заказчик кричал "микросервисы - это круто, хочу, хочу, хочу", а тимлид мне сказал "давай монолит, но так чтоб потом легко было распилить, а то все сроки про**ем". Вот тут прямо вообще понимание пришло. Ну и плюс в Rust архитектурные компоненты очень хорошо ложатся на отдельные крейты (это такая единица компиляции в Rust), а компилятор в принципе не дает делать циклические зависимости между крейтами.

Ну и недавно решил освежить память и перечитать еще раз. И на этот раз уже были мысли вроде "так если делать по другому, потом проблемы вылезут тут и тут".

Глянул на пэт-проект, который сейчас пишу - 5тыс строк + 1тыс тестов, и если честно, ощущение, что проект даже не начал ещё толком писать.

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

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

PS хотел бы ещё важное добавить, архитектурными делами надо заниматься не наскоками. Тут как back-end <-> front-end, мне например сложно перескакивать с одного на другое в течение дня, большие задачи делаю только одно, или back или front.
С архитектурой также надо поступать. Потому, что сложно переключать мышление с глобальных абстракций на детали реализации.