Мне было интересно, какой должна быть гранулярность названий тем в сервис-ориентированной архитектуре, управляемой событиями.
Давайте представим, что у нас есть система управления пользователями, в которой пользователи могут выполнять различные действия, такие как регистрация, подписываниев, изменение некоторых атрибутов профиля и т. д. Если мы хотим уведомить остальные службы об этих изменениях, я могу подумать о некоторых возможностях именования тем:
Одна тема на каждуюиз классических операций 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.