Всем привет Часто вижу тут упоминание таких практик, как репозиторий (в

контексте доступа к БД), разделение пакетов service и api, + все это еще приправлено DI

Мне как человеку с бекграундом Django/flask многое из этого чуждо и непонятно. Я привык как в джанге - есть views, есть models, и т.д.

В связи с этим вопрос - что бы почитать такого, (статьи/книги), чтобы сложить целостное представление об архитектуре веб-приложения на го? Не совсем с нуля, а вот как у меня, с бекграунда другого стека?

Пока вижу только тонны мусорных статей, где описано максимум "как импортировать qin и сделать todolist"
Мне интересно, как сложные проекты делаются в целом.
(+ будет круто, если там же покажется, как этот код сделать тестируемым, но это опционально - могу и отдельно почитать)

ну у тебя была парадигма MVC, а тут другая

чистая архитектура чистый код паттерны gang of four enterprise patterns (https://martinfowler.com/articles/enterprisePatterns.html)

GO тут не причем. Clean architecture

mvc в десктопе. У него adr, mvp.

model-view-controller, не?

mvp это россграм

Да, и это для десктопа.

мало кто понимает что MVC это не MVC. в интернете везде написано что в django/flask это MVC, даже про Spring также написано...

понял

Мало кто понимает, что MVC изначально вообще между V и С не предполагает транспорт ) это чисто паттерн для GUI. В asp MVC у доке типа написали что они так видят MVC и пошло поехало

Лучшая архитектура та, что форсится линтером. Один раз договорились, накидали правила, закинули в CI. Изменения (разработчики взрослеют, меняются взгляды) также только через новые договоренности, которые превращаются в правила. Что там в итоге выберете – чистую или тупой crud в контроллерах – неважно, важно делать это единообразно.

Про мусорные статьи ты верно написал - их тонна. Пойми вот эту статью: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Разные bounded context могут требовать разного уровня проработки. К тому же в процессе развития, в каких-то частях приложения может оставаться говнокод. Проще уж оставить как есть чем менять правила чтобы идти рефакторить для удовлетворения линтера

Линтер либо берется с самого старта, тогда говнокод там оказаться не может, либо уже на готовый проект, тогда подгоняется под правила, а говно в baseline отправляется и не тревожит никого.

Интересно, что в строительной архитектуре, каркас делает инженер-конструктор из конструкторского бюро, по заказу архитектора. А потом на конструкцию натягиваются хотелки заказчика. Т.е. в случае с кодом, конструкция это код и структура директорий. Но она не является первичной. Она вторична, так как создаётся под конкретную архитектуру или архитектурную парадигму или школу

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

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

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

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

Я больше про то умение компоновать паттерны из архитектуры. Если они правильно скомпонованы, но это легче поддерживать так как подводные камни уже известны используемых подходов. А потом переделывать но с учётом тех же критериев. Типа определить недостатки и достоинства каждого из подхода или паттерна который закладывается. Это даёт предсказуемость. А если самотёком все пустить то всегда будет жопа. Абсолютно всегда