Status: Accepted
Date: 2026-04-18
ProtocolGenerator (будущий, Phase 5) нуждается от agenda-сервиса в двух разных типах данных:
Agenda, Question[], Vote[] — JSON ~10 KB, структурированное, нужно обогащение (ФИО, роли).У них разные характеристики I/O, разные retry/timeout политики, разные кеширующие стратегии.
Кроме того — SignatoryService (другой потребитель) нуждается только в Agenda точечно, без вопросов и файлов.
Разделить на два порта:
loadSnapshot(UUID) для bulk-загрузки + getAgenda(UUID) для точечных.download(UUID) возвращает QuestionFile record (byte[] + metadata).Обе реализации лежат в integration/agenda/, под капотом — один Feign-клиент. Раздельные интерфейсы = ISP.
QuestionFile.content как byte[], а не InputStream: файлы комитетов — десятки MB максимум, не гигабайты. byte[] проще в обращении (record с value-equality, нет забытых close()). Миграция на streaming — отдельным ADR если понадобится.
Positive:
ProtocolGenerator.Phase1 мокают только AgendaProvider, не тянут file I/O.SignatoryService зависит только от AgendaProvider, не знает про файлы.Negative:
@Component-класса вместо одного (пусть и в одном файле или смежных).AgendaProvider со всеми методами: нарушает ISP, бьёт по тестируемости, сложная политика ретраев (one-size-fits-all).AgendaSnapshot: загрузка всех файлов заранее при генерации = тонны трафика, неприемлемо.InputStream вместо byte[]: сложнее API, ошибки ресурсов, пока файлы не-большие — overkill.