Концепты GOROCK
Пять идей из которых вырастает вся архитектура. Читай перед тем как смотреть на слои — помогает понять не только что делать, но и почему.
Шаблонность
Мета-концепт. Из него вытекают все остальные.
Боль — каждый Go-проект выглядит по-разному. Приходишь в новый проект — тратишь дни чтобы понять где что лежит и почему именно так. Новый разработчик в команде — снова объяснять с нуля. Переходишь между проектами — каждый раз перестраиваешься.
Идея — бэкенд решает одни и те же проблемы. Принять запрос, обработать, ответить, не упасть. Если проблемы одинаковые — зачем каждый раз придумывать разные решения? Стандарт там где всё одинаково, свобода там где уникально.
Go минималистичен. Бэкенд шаблонен. GOROCK соединяет эти две идеи.
Engine
Боль — HTTP-сервер, consumer, CLI, scheduler — в каждом проекте это выглядит по-разному. Где-то graceful shutdown есть, где-то нет. Где-то retry loop, где-то падает и всё. Где-то логика запуска размазана по трём файлам.
Идея — все эти вещи делают одно и то же: принимают сигнал извне и передают дальше. Они не должны знать что происходит внутри. Один интерфейс для всех движков — Init, Exec, Shutdown, Stop. Всё остальное не его дело.
Формула — любое приложение это движок который знает когда, но не знает что.
Реализация → Engine
Realm
Боль — бизнес-логика размазана везде. Часть в handler, часть в модели, часть в сервисе. Хочешь понять что происходит при запросе — читаешь пять файлов. Хочешь поменять поведение — боишься что-то сломать потому что непонятно где границы.
Идея — всё что видит клиент — это бизнес. Форма запроса, форма ответа, коды ошибок, порядок вызовов — это решения бизнеса, не детали реализации. Одно место где живёт вся эта логика.
Разделение бизнес-логики и транспорта — ложная абстракция. Возврат 500 клиенту — это не деталь HTTP, это бизнес-решение. Engine предоставляет примитивы (коды ошибок, ответы) — Realm использует их для выражения бизнес-решений.
Реализация → Realm
Toolkit
Боль — разработчик пишет SaveUser, GetUserById, DeleteUser — и Postgres превращается из универсального инструмента в хранилище конкретного бизнеса. Завтра нужно сохранять Product — пишет новый сервис с той же логикой. Послезавтра меняет Postgres на MongoDB — переписывает половину проекта потому что бизнес и технология перемешаны.
Идея — инструмент должен оставаться инструментом. Postgres умеет сохранять, находить, фильтровать — это его язык. Что именно сохранять и зачем — это язык бизнеса, он живёт в Realm. Инструмент можно заменить не трогая бизнес.
Сервис экспортирует функционал, не данные. Если метод вынужден что-то вернуть — описывает минимальный тип внутри пакета. Realm маппит это в свои models.
Реализация → Toolkit
Configs
Боль — .env файл с сотней переменных без контекста. DB_HOST, REDIS_PORT, SECRET_KEY — кому это принадлежит? Зачем? Новый разработчик смотрит и не понимает архитектуру приложения. Старый разработчик через полгода тоже не понимает.
Идея — структура configs должна отражать структуру приложения. Открыл один файл — увидел все слои, все зависимости, все технологии. Configs — это не список переменных, это документация которая всегда актуальна потому что без неё приложение не запустится.
Реализация → Конфигурация