Детализация тем в архитектуре, управляемой событиями

Мне было интересно, какой должна быть степень детализации названий тем в сервис-ориентированной архитектуре, управляемой событиями.

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

  1. По одной теме на каждую из классических CRUD-операций в каждой из моделей (исключая чтение, поскольку состояние пользователя не меняется). У нас было бы user-created, user-updated, user-deleted. Этот подход достаточно общий, но потенциально может быть много сервисов, подписанных на тему user-updated и отбрасывающих все те события, которые не изменяют конкретное поле.

  2. Одна тема на каждое важное для бизнеса изменение. В дополнение к user-created и user-deleted у нас могут быть такие события, как user-email-updated, user-signed-in (которое в противном случае было бы запущено как событие user-updated, когда была изменена дата последнего входа в систему) и т. д. Мне кажется, что даже если это было бы удобно для тех подписчиков, которые заинтересованы только в очень конкретном изменении, тем службам, которым необходимо синхронизировать все, что происходит с пользователем, будет сложнее, поскольку им придется подписываться на все большее количество тем, чтобы отслеживать все изменения в пользовательская модель.

  3. Сочетание между 1 и 3, где оба события user-updated и user-email-updated будут отправлены, когда пользователь обновит электронную почту, но только user-updated будет отправлено, если пользователь изменит профиль.

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
1
3
293
1

Ответы 1

Лучше всего реализовать второй вариант, но реализовать его с помощью иерархии тем, чтобы подписчики могли выбирать интересующую их степень детализации (например, при подписке на пользователей.* или *.updated или user.actions.login и т. д.).

Некоторые технологии (например, RabbitMQ) имеют эту встроенную возможность, для других вы можете реализовать реестр тем и предоставить инфраструктуру для самостоятельного управления подписками.

Другие вопросы по теме