Сервис и бизнес-логика

Открой официальную FAQ — она требует от service-слоя чистоты по канонам Clean Architecture и Hexagonal Architecture, и это не украшение, а рабочее правило. Сервис — это интерфейс и его реализации: здесь принимаются бизнес-решения, валидируются доменные правила, считается результат. Запрещено транспортное: никаких *http.Request, gRPC-кодов, json-тегов и логов уровня «получен POST». Запрещено и инфраструктурное по мелочи: глобальные синглтоны, чтение env в глубине метода, тайные обращения к пакету os — всё это зависимости, и им место в конструкторе. Разрешено: работа с доменными моделями, вызовы других сервисов и интерфейсов-хранилищ, sentinel-ошибки домена. Проверка на честность простая: если файл с сервисом компилируется без единого транспортного импорта и его можно собрать в тесте одной строкой — слой чистый. Именно поэтому go-kit сервис называют самым скучным и самым дорогим слоем курса: скука — это дисциплина, а дисциплина — это возможность менять транспорт и хранилище, не трогая бизнес.

Всё начинается с интерфейса — в go kit сервис по определению является интерфейсом, а не структурой. Смотри на stringsvc: StringService объявляет два метода, Uppercase и Count, и в сигнатурах — только context.Context и доменные типы. Урок 10 продвинутого курса учил: интерфейсы маленькие и объявляются у потребителя; здесь потребитель — адаптеры endpoint'ов и декораторы, поэтому интерфейс описывает ровно те операции, что видит наружу. Обрати внимание на ctx в каждом методе: даже если сейчас контекст не нужен, он появится, когда сервис подрастёт и начнёт звать базу с дедлайном; заложи его сразу, чтобы не ломать сигнатуры. Имя интерфейса — по домену, а не по слою: StringService, ProfilesService, OrdersService. И не плодь гигантов: интерфейс на десять методов — сигнал, что сервис просится разделить. Первым уроком курса мы уже видели этот интерфейс в func main — сегодня он получает тело и начинает работать.

Бизнес-отказы надо называть, и для этого в Go есть sentinel-ошибки: значения уровня пакета, созданные errors.New. stringsvc объявляет var ErrEmpty = errors.New("empty string") — сервис возвращает её, когда нечего аперкейсить. Три причины держать sentinel-ошибки. Первая — договорённость: вызывающий код может проверить errors.Is(err, ErrEmpty) и отреагировать точно, не парсингом строк. Вторая — перевозимость: ошибка едет в Err-поле response-структуры через Failer (урок 02), и транспорт на уроке 04 превратит её в HTTP-статус через таблицу codeFrom — sentinel сработает и там. Третья — документация: список var Err... в начале файла сервиса читается как меню возможных отказов. Правила hygiene: sentinel-ошибки экспортируются только если их проверяет чужой код; текст пишется строчными, без точки; не плодить по одной на каждый if — если ошибка ни для кого не различима, обобщённой хватит. И никогда не оборачивай sentinel строкой до errors.Is — сравнение по значению умирает при fmt.Errorf без %w.

Растущий сервис тянет за собой хранилище, и вот тут принимается архитектурное решение на годы. Правило go kit: зависимости объявляются интерфейсами и передаются конструктором. Хранилище — интерфейс Repository, объявленный у потребителя, то есть сервисом; конкретная реализация — память, Postgres, что угодно — пишется отдельно и приходит снаружи. Конструктор NewService принимает интерфейс и возвращает интерфейс сервиса: main собирает граф, тест подсовывает заглушку, никто не лезет в глобальные переменные. Это ровно та честность зависимостей, о которой говорил первый урок: если компоненту нужен логгер или репозиторий — он получает их параметром. Сравни с типовым gin-проектом, где хендлер сам открывает *gorm.DB из глобалки: там тест требует живую базу, а здесь — строку кода. Отдельное правило про nil: конструктор обязан паниковать или возвращать ошибку на nil-зависимости, потому что nil-репозиторий взорвётся в рантайме на первом запросе — лучше громко упасть на старте.

Первый урок обещал вернуться к service middleware — второй вид обёрток в go kit. Endpoint middleware оборачивает функцию; service middleware оборачивает интерфейс сервиса: type LoggingMiddleware func(StringService) StringService. Каноническая реализация — встраивание: структура loggingMiddleware включает StringService и переопределяет только нужные методы, вызывая base и дописывая поведение вокруг. Это декоратор в чистом виде: обёртка реализует тот же интерфейс, поэтому main может навесить хоть пять штук подряд, и тип не изменится — svc остаётся StringService. Что уносим в декораторы: логирование на уровне домена, метрики бизнес-событий, кэш, ретраи к хранилищу. Что остаётся в реализации: сама бизнес-логика. Разница с endpoint-обёртками практическая: декоратор видит доменные аргументы («в Uppercase передали пустую строку»), а endpoint-обёртка — структуры транспорта; логи уровня бизнеса делаются сервисными middleware, логи уровня запроса — endpoint'ными. В уроке 15 разложим их по полочкам, сегодня — первый рабочий образец.

Вот зачем всё затевалось. Сервис — интерфейс без транспорта, значит тест собирает его одной строкой: svc := stringService{} или NewService(stubRepo). Никакого HTTP-сервера, ни JSON, ни портов — тест гоняется в микросекунды и не знает flaky. Форма — table-driven, штатный стиль Go: срез кейсов с именами, цикл по ним и t.Run на каждый; упавший кейс называет себя сам. Что покрывать: счастливый путь, граничные значения, sentinel-ошибки через errors.Is. Что НЕ покрывать на этом уровне: декодирование JSON (это транспорт, уроки 04 и 16), статусы HTTP, заголовки. Практика команд: бизнес-тесты — десятки кейсов на метод и прогон на каждый коммит; транспортные — несколько дымовых. Если тесту сервиса нужна живая база — это красный флаг: либо тест транспортный по духу, либо хранилище прячется за интерфейсом, и тогда заглушка в двадцать строк решает вопрос. На уроке 16 добавим тесты endpoint'ов и транспорта — но скелет надёжности строится здесь.

Как только у сервиса появились зависимости, тест расщепляется: логика тестируется с заглушкой хранилища. Stub — минимальная реализация интерфейса Repository, достаточная для кейса: сохранить значение в карту, вернуть его по Get, а в режиме «злобной заглушки» — всегда отдавать ошибку, чтобы проверить ветку инфраструктурного сбоя. Обрати внимание, где объявлен stub: в тестовом файле, рядом с тестом, а не в общем пакете — интерфейс маленький, поэтому заглушка компактная; если Stub разросся, это сигнал, что интерфейс потолстел. Сценарий теста PostProfile: подсовываем memory-заглушку, зовём метод, проверяем, что id вернулся и Save действительно вызван с тем же значением; затем злобный stub — и убеждаемся, что ошибка хранилища прошла наверх по каналу err, не превратившись в бизнес-ответ. Так тестируются все зависимости курса: Repository, кэш, очередной клиент. Заметь дивиденд канонической сборки: декоратор LoggingMiddleware в тесте не нужен — логи проверяются отдельно, а можно наоборот обернуть сервис декоратором и проверить, что лог записан; обе проверки чистые, потому что всё через интерфейсы.

Домен готов и проверен — сервис не знает, как его вызывают, и это правильная позиция. Осталась последняя стена между бизнесом и внешним миром: урок 04-http-transport собирает kithttp.NewServer, декодеры и энкодеры, а заодно раскладывает ошибки транспорта по HTTP-статусам. Для разогрева вернись к уроку 02-endpoint — там мы строили адаптеры, которые сейчас заработают по-настоящему; общая карта слоёв — в уроке 01-filosofiya, программа всего маршрута — на странице курса.