Архитектура Bank Recommendation Service - Rzavsky-ev/StarBank GitHub Wiki

Диаграмма компонентов приложения, которая показывает внешние взаимодействия системы:

componentDiagram %% Внешние системы component "Telegram" as tg component "Клиентское приложение" as client component "Система мониторинга" as monitoring

%% Основные компоненты
component "API Gateway" {
    component "RecommendationController"
    component "RuleController"
    component "ManagementController"
}

component "Сервисный слой" {
    component "RecommendationService"
    component "RuleService"
    component "TelegramBotService"
}

component "Репозитории" {
    component "UserDataRepository"
    component "DynamicRuleRepository"
}

component "Базы данных" {
    database "H2 (транзакции)" as h2
    database "PostgreSQL (правила)" as pg
}

%% Взаимодействия
tg --> API Gateway : Запросы рекомендаций
client --> API Gateway : REST API
monitoring --> API Gateway : /management/health

API Gateway --> "Сервисный слой"

"Сервисный слой" --> "Репозитории" : Данные
"Репозитории" --> h2 : Read-only
"Репозитории" --> pg : Read/Write

note right of "Сервисный слой"
    Кеширование результатов:
    - Caffeine
    - 3 уровня (по типам запросов)
end note

Ключевые элементы архитектуры

Внешние вызовы (стрелки внутрь):

• Telegram — запросы от пользователей через бота
• Клиентские приложения — мобильные/веб-приложения банка
• Система мониторинга — проверка здоровья сервиса
• Админ-панель — управление правилами менеджерами

Внешние системы (стрелки наружу):

• H2 Database — чтение транзакционных данных
• PostgreSQL — хранение динамических правил
• (Неявно) Telegram API — для отправки сообщений

Критические пути данных:

graph LR A[Клиент] --> B[API Gateway] B --> C[Сервис рекомендаций] C --> D[Кеш] C --> E[Репозиторий транзакций] E --> F[H2] C --> G[Репозиторий правил] G --> H[PostgreSQL]

Технологии подключения:

• К H2: — JdbcTemplate (JDBC)
• К PostgreSQL: — Spring Data JPA
• Кеш: — Caffeine (in-memory)

Диаграмма деятельности (Activity Diagram) для алгоритма выдачи рекомендаций с учетом как статических, так и динамических правил:

activityDiagram title Алгоритм выдачи рекомендаций start :Получить запрос с user_id;

partition Инициализация {
    :Загрузить профиль пользователя из H2;
    :Загрузить статические правила (хардкод);
    :Загрузить динамические правила из PostgreSQL;
}

partition Проверка правил {
    fork
        :Проверить статические правила|
        note right: 3 фиксированных правила\nиз ТЗ (Invest 500, Top Saving, Простой кредит);
        
        :Проверить динамические правила|
        note left: Правила из БД\nс JSON-логикой;
    fork again
        :Проверить кеш рекомендаций|
        note: Кеширование результатов\nпо user_id;
    end fork
    
    :Объединить результаты;
}

partition Финализация {
    if (Есть подходящие продукты?) then (да)
        :Обновить статистику срабатываний;
        :Записать в кеш;
        :Сформировать ответ с рекомендациями;
    else (нет)
        :Вернуть пустой список;
    endif
}

stop

Входные данные:

• user_id: — идентификатор пользователя
• Статические правила — 3 бизнес-правила из ТЗ
• Динамические правила — из таблицы dynamic_rules

Ключевые этапы:graph TD

A[Старт] --> B[Загрузка данных] B --> C[Параллельная проверка] C --> D{Есть совпадения?} D -->|Да| E[Сбор статистики] D -->|Нет| F[Пустой ответ] E --> G[Кеширование]