directory-structure-go

Личный стандарт для реализации микросервисов

Структура сбалансирована между гибкостью и практичностью, соответствует принципам Clean Architecture и DDD. Ниже расписал детальные определения для каждой директории:

---

Корневые директории

Директория	Назначение
cmd/	Точки входа в приложение (например, main.go). Может содержать поддиректории для разных сервисов (API, миграции, CLI).
config/	Конфигурация приложения (env-переменные, YAML/JSON-файлы). Логика парсинга конфигов.
internal/	Скрытая реализация логики (контракты, инфраструктура, техническая часть).
pkg/	Общесервисные утилиты, которые могут использоваться другими микросервисами. Только то, что действительно нужно шарить (например, testutils).

---

Директории внутри internal/

1. app/

Директория/Файл	Назначение
/	Dependency Injection (сборка всех зависимостей). Инициализирует сервисы, адаптеры, репозитории.

2. domain/ (Ядро системы)

Директория	Назначение
models/	Сущности, Value Objects, Агрегаты. Чистые структуры данных без логики.
ports/	Интерфейсы для взаимодействия с внешним миром: • repository/ – для работы с данными (например, UserRepository). • service/ – абстракции бизнес-логики (например, PaymentService).
rules/	Чистая бизнес-логика: валидация, статические методы, неизменяемые правила.

3. infrastructure/ (Реализации портов)

Директория	Назначение
adapters/	Адаптеры для инфраструктуры: • cache/ – Redis, Memcached. • logger/ – Zap, Logrus. • router/ – Gin, Echo.
clients/	Клиенты для внешних API (Stripe, SMTP, Kafka).
persistence/	Реализации репозиториев из domain/ports/repository/ (Postgres, MongoDB).
services/	Реализации бизнес-логики (сервисов из domain/ports/service/). Оркестрируют вызовы домена и адаптеров.

4. interfaces/ (Входные точки)

Директория	Назначение
http/	Всё для HTTP API: • dto/ – Data Transfer Objects (запросы/ответы). • handlers/ – обработчики запросов (вызывают сервисы). • server/ – роутинг, middleware, CORS.

---

Почему это работает?

1. Чистый домен
   domain/ не зависит от других слоёв. Можно менять БД или фреймворк без изменений в бизнес-логике.

2. Гибкость

   • Замена логгера (Zap → Logrus) → правки только в infrastructure/adapters/logger/.
   • Добавление нового API → новый клиент в infrastructure/clients/.

3. Тестируемость

   • Домен тестируется юнит-тестами.
   • Сервисы тестируются с моками (репозиториев, клиентов).

4. Масштабируемость

   • Новые сущности → добавляются в domain/models/.
   • Новые сценарии → новые сервисы в infrastructure/services/.

---

Примеры зависимостей

1. HTTP-запрос:

   HTTP Handler → Infrastructure Service → Domain Ports → Persistence Adapter
   

2. Логирование:

   Domain Service → Logger Interface (port) → Zap Adapter (infra)
   

---

Что можно добавить?

1. interfaces/events/ – для подписки на события (Kafka, RabbitMQ).
2. infrastructure/workers/ – фоновые задачи (cron, воркеры).
3. api/ в корне – OpenAPI/Swagger-спецификации (если API публичное).

---

Предварительный итог

Ваша структура выгляди хорошо для:

• Средних и крупных микросервисов.
• Команд, работающих по DDD/Clean Architecture.
• Проектов, где важны тестируемость и гибкость.

---

Контакты

Telegram