👋Тут на выходных в соседнем телеграмм канале я увидел крик души. Человек пытается сделать благое дело — описать простую, прагматичную архитектуру для Go. Он хочет собрать сбалансированный, проверенный набор принципов, паттернов и примеров кода, который можно взять за основу для реальных проектов.
И знаете, что я об этом думаю? Это одновременно и прекрасно, и ужасно.
Прекрасно — потому что это глоток здравого смысла среди всего этого карнавала с DDD, Clean Architecture и гексагонами, которые пихают в каждый CRUD-сервис на три с половиной ручки.
А ужасно — потому что сама потребность в такой «инструкции» — это диагноз всей нашей индустрии.
Человек пытается написать простую, внятную поваренную книгу. А знаете, почему она нужна? Потому что 90% команд разучились жарить яичницу, но пытаются повторить рецепт из мишленовского ресторана. Начитаются Фаулера, насмотрятся докладов и тащат в свой проект репозитории, юзкейсы, адаптеры, порты...
В итоге простейший сервис превращается в монстра из десятка слоев абстракций, где для изменения одной строчки SQL надо поправить семь файлов. И все это не для пользы дела, а для строчки в резюме.
🔥Так вот, запомните. Хорошая архитектура — это не та, в которую нечего добавить, а та, из которой нечего убрать. Ваша задача — решать проблему бизнеса, а не строить собор по всем канонам.
Начинайте с тупого монолита с пакетами по фичам (`feature-based layout`). Когда реально понадобится — вынесете интерфейс, добавите слой. Не раньше.💯
Инициатива — абсолютно правильная. Возможно, хоть такая инструкция для самых маленьких заставит людей сначала думать, а потом — добавлять зависимости.
#заметкинаполях
Токсичный (it) архитектор
И знаете, что я об этом думаю? Это одновременно и прекрасно, и ужасно.
Прекрасно — потому что это глоток здравого смысла среди всего этого карнавала с DDD, Clean Architecture и гексагонами, которые пихают в каждый CRUD-сервис на три с половиной ручки.
А ужасно — потому что сама потребность в такой «инструкции» — это диагноз всей нашей индустрии.
Человек пытается написать простую, внятную поваренную книгу. А знаете, почему она нужна? Потому что 90% команд разучились жарить яичницу, но пытаются повторить рецепт из мишленовского ресторана. Начитаются Фаулера, насмотрятся докладов и тащат в свой проект репозитории, юзкейсы, адаптеры, порты...
В итоге простейший сервис превращается в монстра из десятка слоев абстракций, где для изменения одной строчки SQL надо поправить семь файлов. И все это не для пользы дела, а для строчки в резюме.
🔥Так вот, запомните. Хорошая архитектура — это не та, в которую нечего добавить, а та, из которой нечего убрать. Ваша задача — решать проблему бизнеса, а не строить собор по всем канонам.
Начинайте с тупого монолита с пакетами по фичам (`feature-based layout`). Когда реально понадобится — вынесете интерфейс, добавите слой. Не раньше.💯
Инициатива — абсолютно правильная. Возможно, хоть такая инструкция для самых маленьких заставит людей сначала думать, а потом — добавлять зависимости.
#заметкинаполях
Токсичный (it) архитектор