Введение в архитектуру Go-сервисов

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

В Go архитектурные подходы обычно выглядят проще, чем в Java-мире: меньше наследования, больше явных интерфейсов, пакетов и функций. Но простота не отменяет дисциплину. Если границы не обозначены, бизнес-логика быстро смешивается с HTTP, базой, очередями и случайными деталями инфраструктуры.

Что будет внутри

• layered architecture как базовая точка отсчёта;
• hexagonal и onion architecture: ports, adapters, направление зависимостей;
• Clean Architecture и практическая раскладка по пакетам;
• сравнение подходов без попытки выбрать один навсегда;
• DDD: язык предметной области, entities, value objects, aggregates;
• паттерны, которые в Go действительно встречаются в живом коде.

Как теория связана с проектом RateDesk

Теоретические уроки разбирают архитектурные решения отдельно: layered, ports/adapters, use cases, DDD, aggregates, patterns. Практическая сборка этих решений живёт в отдельном проектном треке RateDesk, особенно на этапе Architecture.

Поэтому в уроках ниже будут короткие production-примеры и анти-примеры, а не полноценные проектные задания. Детальные issue, acceptance criteria, MR-план, ADR и review checklist должны жить в проекте, где студент реально меняет код.

Связка простая:

• в теории студент понимает правило и видит небольшой пример;
• в RateDesk применяет правило к ConvertAmount, rate provider, repository boundary, config, idempotency и outbox;
• на review проверяет не «похожесть на Clean Architecture», а конкретные свойства: нет циклов импортов, use case тестируется без БД, домен не знает про pgx, echo, Redis, Kafka и внешние SDK.

Как понять, что модуль освоен

Вы можете объяснить, почему один пакет зависит от другого, где живёт бизнес-правило и что нужно изменить при замене базы, HTTP-фреймворка или внешнего клиента. Вы не создаёте слои ради слоёв, но и не складываете всё в один handler.

Главный результат: вы умеете выбирать структуру под размер задачи. Маленькому сервису не нужна тяжёлая церемония, большому сервису опасно жить без границ.

Рабочие ориентиры

• Архитектура должна защищать важные правила от деталей доставки и хранения.
• Интерфейс обычно объявляет потребитель, а не поставщик.
• Чем дороже изменение, тем явнее должна быть граница вокруг него.