Начните с простой структуры и выделяйте пакеты по связной ответственности. cmd — распространённое место для команд, internal ограничивает допустимый импорт, а pkg не обязателен и не имеет специальной семантики Go. Структура должна помогать понимать зависимости и тестировать код, а не копировать шаблон для большого проекта.
Как выбрать структуру проекта на Go?
Как организовать пакеты по назначению и масштабу, не принимая cmd/pkg/internal за обязательный стандарт каждого проекта.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Структура зависит от того, что вы создаёте: библиотеку, небольшую CLI-команду или сервер с несколькими точками запуска. Маленькому проекту может хватить go.mod и нескольких файлов одного пакета. Не нужно заранее создавать десятки пустых каталогов.
Для растущего сервиса возможен такой пример:
service/
go.mod
cmd/
server/
main.go
internal/
orders/
transport/
storage/
api/
docs/
Это иллюстрация, а не обязательный стандарт. В cmd удобно держать входные точки, оставляя main сборку зависимостей и запуск. Пакеты объединяют связные типы и операции, а не просто все «модели» или все «утилиты» без общего назначения.
У internal есть проверяемое инструментами Go ограничение: код под таким каталогом можно импортировать только из дерева, корнем которого является родитель internal. Каталог pkg, напротив, не обладает специальной языковой семантикой и не обязателен. Публичные библиотечные пакеты могут находиться и без него. Разные варианты показывает официальное руководство.
Стремитесь к понятному направлению зависимостей и избегайте циклических импортов. При необходимости отделяйте предметную логику от транспорта и хранения через небольшие контракты, но не создавайте интерфейс для каждого типа автоматически.
Структура не должна раскрывать секреты: каталог configs не является поводом коммитить production-пароли. Завершите ответ примером того, как выбранное разбиение помогало изменять или проверять код. Названия папок сами по себе не доказывают качество архитектуры.