Standard Go Project Layout

Что это такое

Standard Go Project Layout — репозиторий с примером структуры Go-проекта. Он стал популярным, потому что в самом Go мало обязательных правил про каталоги, а командам все равно нужен общий язык для команд, внутреннего кода, публичных пакетов и развертывания.

Важно понимать его статус: это не спецификация Go и не требование компилятора. Это набор практик, который помогает обсудить структуру проекта до того, как в репозитории появятся десятки несвязанных папок.

Что внутри репозитория

Внутри описаны каталоги вроде cmd, internal, pkg, api, web, configs, scripts, deployments и test. Для каждого есть короткое объяснение, зачем он может быть нужен и когда его лучше не добавлять.

Ценность проекта не в том, чтобы копировать дерево целиком. Наоборот, хороший результат — взять только те части, которые отражают реальный продукт: одну команду в cmd, закрытый код в internal, публичные пакеты только там, где они действительно нужны.

Как используют

Репозиторий часто используют как отправную точку при создании сервисов на Go, особенно когда проект должен пережить первые несколько месяцев роста. Он помогает заранее договориться, где лежат исполняемые команды, где доменная логика, где вспомогательные скрипты и где файлы для окружения.

Для маленькой утилиты такая структура может быть избыточной. Если весь проект помещается в несколько файлов, лучше начать проще и добавить каталоги только после появления реальной причины.

Сильные стороны и ограничения

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

Главное ограничение — риск культового копирования. Пустые каталоги не делают проект зрелым. В Go особенно важно держать структуру короткой, пока код сам не показывает, какие границы ему нужны.

Хороший способ использовать этот репозиторий — начинать с вопроса о границах ответственности. Если каталог internal отделяет код приложения от публичных пакетов, он приносит пользу. Если pkg появляется только потому, что так выглядит пример, структура начинает мешать.

В Go особенно легко создать лишнюю архитектуру раньше времени. Поэтому этот шаблон полезнее как список вариантов, чем как готовая инструкция. Он помогает команде назвать вещи, но окончательная структура должна следовать реальному коду.

Пример

myservice/
  cmd/api/main.go
  internal/orders/service.go
  internal/http/routes.go
  configs/local.yaml
  go.mod