Comments 8
Позвольте стать первым в комментариях к вашему труду (спасибо за него, вы не дурно излагаете!), кто скажет что использовать слово “framework” в одном предложении с “Go” сразу вызовет если не волну, то некоторый всплеск негодования - почти наверняка.
Хотел бы задать лишь один вопрос - чем (на ваш взгляд) плох подход “поглядывай на project-layout, когда сомневаешься как разместить файлики, да на большие проекты типа k8s/docker, но воспринимай их просто лучшую устоявшуюся практику, но не ограничивай себя ими”?
Спасибо за комментарий и добрые слова.
Я не считаю такой подход плохим, более того именно так и я поступил. Сначала посмотрел на похожие структуры проектов, и текущая структура до сих пор во многом на них опирается.
Со временем такое решение мне показалось немного неудобным, и я организовал его немного по-другому. Собрал всё в структуру, собрал нужные пакеты и сделал из этого темплейт. Ну и добавил несколько пакетов и врапперов от себя для решения своих задач.
И сама статья всё-таки больше о поиске баланса и о том, чтобы не впадать в крайности и не бояться отступить от догмы, если так лучше для проекта. То есть смотреть на архитектурную дисциплину через призму конкретного проекта.
Framework в статье скорее выступает как пример одной из возможных реализаций такого подхода. Он подходит под мои задачи, но не обязательно подойдёт всем.
Производительность часто приносится в жертву академической чистоте
Ну и чушь, а когда я увидел что у вас "свободная" архитектура производительнее чем чистая, то даже читать перестал)
Производительность часто приносится в жертву академической чистоте.
С точки зрения строгой архитектурной чистоты здесь возникает асимметрия: для записи у нас остаются доменные сущности, сервисы, репозитории и транзакции, а для чтения появляется отдельный optimized read‑path. Это уже не выглядит так «красиво», как каноническая layered‑схема, но в production такая асимметрия часто оказывается оправданной.
Огромное заблуждение считать что есть какая-то архитектурная чистота и каноничность. Все эти чистые архитектуры и DDD это не более чем завирусившиеся авторские методики отдельных скучающих писателей. Будучи объективным нужно сказать что нет никаких хотя бы околонаучных доказательств что вся эта многослойность, вся эта эмуляция реального мира, вся эта чисто-архитектурность дает пользы больше чем вреда. Да по папочкам разложено, да уложено приложено, все реализации поменять можно, вот только там где в нормальном проекте для доработки хватить пары строк, в книжных архитектурах все будет когнитивно переусложнено, раскидано по десяткам классов и будут уходить часы, дни и недели на обсуждения архитектурной частоты согласно книжке и будет написаны тысячи строк кода которые решают проблемы которая такая архитектура и создала и не имеют никакой практической ценности для практической задачи.
Это я к чему. Наверное не стоит делать такие противопоставления. Делать из перехайпленых книжных подходов какой то эталон. Под задачу выбираем инструменты а не под инструменты подгоняем задачу.
Есть масса отличных статей про то как писать код на Go от создателей Go, но народ зачем-то читает "экспертов", которые пытаются всё переусложнить, пытаются натянуть ООП-эшные подходы на Go.
Есть отличная статья от создателей Go по поводу организации кода в проекте, но народ продолжает натягивать сову на глобус, преподнося это как высшее знание, как эталон разработки.
За свои 10+ лет в Go я повидал не мало проектов и не мало создал сам. Могу сказать наверняка, нет архитектуры лучше, чем просто лежащие в корне проекта файлики, без этих ваших бесконечных репозиториев, сервисов, юзкейсов, без попыток бездумно "обмазать" всё интерфейсами, без мапинга структур на каждом повороте, без "кастрирующих" обёрток над действительно хорошими решениями.
К сожалению, такие слова про простоту проекта без репозиторием, сервисов, оберток и т.д. остаются голословными утверждениями. Многие говорят, что это всё не нужно, но ни разу не видел крупный (практически production-ready) проект, написанный таким образом и который бы можно было ставить в пример вариантам с усложнениями и говорить: "Вот пример простого и крупного проекта".
Рад буду ошибиться и увидеть ссылку на репозиторий такого проекта "без усложнений".
В поисках баланса в backend-архитектуре