Мне было интересно, какой должна быть степень детализации названий тем в сервис-ориентированной архитектуре, управляемой событиями.
Давайте представим, что у нас есть система управления пользователями, в которой пользователи могут выполнять различные действия, такие как регистрация, вход в систему, изменение некоторых атрибутов профиля и т. д. Если мы хотим уведомить остальные службы об этих изменениях, я могу придумать некоторые возможности для название темы:
По одной теме на каждую из классических CRUD-операций в каждой из моделей (исключая чтение, поскольку состояние пользователя не меняется). У нас было бы user-created
, user-updated
, user-deleted
. Этот подход достаточно общий, но потенциально может быть много сервисов, подписанных на тему user-updated
и отбрасывающих все те события, которые не изменяют конкретное поле.
Одна тема на каждое важное для бизнеса изменение. В дополнение к user-created
и user-deleted
у нас могут быть такие события, как user-email-updated
, user-signed-in
(которое в противном случае было бы запущено как событие user-updated
, когда была изменена дата последнего входа в систему) и т. д. Мне кажется, что даже если это было бы удобно для тех подписчиков, которые заинтересованы только в очень конкретном изменении, тем службам, которым необходимо синхронизировать все, что происходит с пользователем, будет сложнее, поскольку им придется подписываться на все большее количество тем, чтобы отслеживать все изменения в пользовательская модель.
Сочетание между 1 и 3, где оба события user-updated
и user-email-updated
будут отправлены, когда пользователь обновит электронную почту, но только user-updated
будет отправлено, если пользователь изменит профиль.
Лучше всего реализовать второй вариант, но реализовать его с помощью иерархии тем, чтобы подписчики могли выбирать интересующую их степень детализации (например, при подписке на пользователей.* или *.updated или user.actions.login и т. д.).
Некоторые технологии (например, RabbitMQ) имеют эту встроенную возможность, для других вы можете реализовать реестр тем и предоставить инфраструктуру для самостоятельного управления подписками.