@Lavlet

Оправдано ли применение очередей сообщений и архитектуре с событийной моделью?

Есть сервис, который принимает запросы по REST на какие-то выборки данных. Изменение и добавление данных также проводится через него. Необходимо уведомлять сервисы, которые подпишутся на это, об изменении данных.
Думал об архитектуре Сервис данных -> Диспетчер подписок (принимает собтие и распределяет сообщения по очередям, также хранит кто подписался на какое-либо событие) -> Очереди сообщений -> Подписчики.

Как думаете, насколько оправдана ли такая архитектура? Может быть есть какой-то известный паттерн проектирования, который не увидел, что описывает подобную задачу?
  • Вопрос задан
  • 236 просмотров
Пригласить эксперта
Ответы на вопрос 2
ApeCoder
@ApeCoder
Описано в книжке Фаулера, например

https://www.enterpriseintegrationpatterns.com/patt...
Ответ написан
Комментировать
AlexanderYudakov
@AlexanderYudakov
C#, 1С, Android, TypeScript
Регулярно использую похожую конструкцию. Пара моментов:
1. Никогда не использую внешние универсальные очереди сообщений (MSMQ etc). Вместо этого - легкое простое специализированное решение для каждого конкретного случая.
2. Всегда интегрирую в единое целое то, что вы называете "сервис данных", "диспетчер подписок" и "очереди сообщений".
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы