Как вы структурируете свои серверные проекты Go? Каковы ваши соображения по организации кода в пакеты?

Единой «официальной» структуры не существует, но общие шаблоны и соображения включают:

• cmd: Основные приложения (например, cmd/api, cmd/worker). Каждый содержит main.go.

• pkg: код библиотеки, предназначенный для использования внешними приложениями (реже встречается в серверных модулях с одним сервисом, чаще для общих библиотек).

• internal: Частный код приложения, не предназначенный для внешнего использования (бизнес-логика, обработчики, реализации репозитория). Часто это ядро ​​серверной службы.

• api: определения API (например, буферы протоколов, спецификации OpenAPI).

• configs: Файлы конфигурации.

• migrations: файлы миграции базы данных.

• vendor: Зависимости от поставщика (если не используется прокси-сервер модуля).

• Организация пакета:

• Связность: Группируйте связанные типы, функции и методы в один пакет. В идеале пакет должен иметь единую и четкую ответственность.

• Связь: Минимизируйте зависимости между пакетами. Пакеты должны зависеть от абстракций (интерфейсов), а не от конкретных реализаций, где это возможно.

• Принципы доменно-ориентированного проектирования (DDD): Организуйте пакеты вокруг бизнес-доменов или ограниченных контекстов (internal/users, internal/orders, internal/payments).

• Уровни. Разделяйте проблемы на уровни (например, обработчики, сервисы/варианты использования, репозитории). handlers зависят от services, services зависят от repositories. Это способствует тестируемости и ремонтопригодности.

• Избегайте циклических зависимостей. Компилятор Go запрещает циклический импорт между пакетами.

Итог

Единой «официальной» структуры не существует, но общие шаблоны и соображения включают:

• cmd: Основные приложения (например, cmd/api, cmd/worker).