Допустимы ли REST запросы между сервисами в событийно-ориентированной архитектуре?

Question

[BITniki]

Изучаю СОА и пытаюсь написать пример на её основе. В ходе проектирования возник вопрос, который у меня не получается нагуглить.

Коротко: при обработке события сервису требуется информация, за которую отвечает другой сервис. Нормально ли делать синхронный запрос из одного сервиса в другой для получения этой информации или это плохой дизайн?

Длинно:
Я разрабатываю сервис для настройки подключений к моему ВПН хосту. Юзер через тг бота может получить конфиг и поднять туннель. Доступ платный, по подписке, на разных уровнях подписки доступно разное кол-во активных конфигов.

Я выделил три сервиса:
- Тг бот -- фронтенд сервиса
- Сервис подписок (СП) -- хранит информацию о подписках юзеров, обрабатывает платежи
- Сервис управления подключениями (СУП) -- управляет подключениями юзеров

Тг бот может выводить пользователю существующие уровни подписки, текущую подписку, существующие подключения. Соответственно тг боту требуется запрашивать эту информацию у других сервисов. Городить костыли в виде запроса данных через брокера кажется излишним. Но нормально ли ему делать REST запросы конкретно к этим сервисам или, может, стоит выделить отдельный сервис для получения подобной "справочной" информации, который будет работать напрямую с бд.

Или вот обработка события "создания нового подключения":
- Бот кладёт в брокера заявку на создание нового подключения
- СУП получает заявку, валидирует, после чего создаёт новое подключение
Для валидации заявки СУПу требуется информация о текущей подписке пользователя. Нормально ли сделать REST запрос в СП? Или лучше сразу запаковать эту информацию с заявкой? Но тогда это будто просто перенос обязанности
сдалать запрос от СУП к тг боту и смысла много не имеет

Comments

[Everything_is_not_so_bad]

ИИ бот пишет

Варианты реализации:

1. REST запросы: ТГ бот может напрямую отправлять REST запросы к сервисам Подписок и Управления подключениями, чтобы получить требуемую информацию. Однако это может привести к следующим проблемам:
   
   • ТГ бот становится зависимым от конкретной реализации сервисов Подписок и Управления подключениями.
     
   • ТГ бот может получить доступ к внутренней логике сервисов, что может нарушить принципы разделения обязанностей и монолитности.
     
   
   
   
2. Сервис справочной информации: Вы можете создать отдельный сервис, который будет хранить и обрабатывать справочную информацию о подписках и подключениях. ТГ бот будет отправлять запросы к этому сервису, а он, в свою очередь, будет обращаться к сервисам Подписок и Управления подключениями. Это может сделать систему более масштабируемой и гибкой, но требует дополнительных затрат на разработку и поддержку.
   
3. События: Вы можете использовать события для передачи информации от сервисов Подписок и Управления подключениями к ТГ боту. Например, когда пользователь создает новую подписку, сервис Подписок может отправить событие о создании подписки, а ТГ бот может обрабатывать это событие и обновлять информацию о подписках пользователя.
   

Обработка события "создания нового подключения":

1. REST запрос к СП: СУП может отправлять REST запрос в СП, чтобы получить информацию о текущей подписке пользователя. Это может быть нормальным подходом, если СУП не имеет доступа к информации о подписках и не может обновлять эту информацию напрямую.
   
2. Запаковывать информацию с заявкой: СУП может запаковывать информацию о текущей подписке пользователя в заявку на создание подключения. Это может быть нормальным подходом, если СУП имеет доступ к информации о подписках и может обновлять эту информацию напрямую.
   

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