Событие пожарного сообщения, только когда эти другие сообщения были отправлены

Question

Я работаю над созданием решения для микросервиса, где большая часть кода будет C # и, скорее всего, Angular для любого внешнего интерфейса. Мой вопрос о цепочке сообщений. Я все еще выясняю, какой брокер сообщений использовать;Сервисная шина Azure, RabbitMQ и т. Д. Есть концепция, о которой я не очень много знаю.

Как мне обрабатывать случаи, когда я хочу запустить сообщение, когда сработал определенный набор сообщений. Пример, но не часть моего фактического решения: я хочу сказать, Уведомить кого-то, когда оплачивает счет. Мы отправляем сообщение "PAIDBILL", в котором запускаются микросервисы, которые будут обрабатываться независимо:

1. FinanceService для дебетования регистра и запуска "PaymentPosted"

2. EmailService: клиент электронной почты, говорящий спасибо за оплату счета "CustomerPaymentEmailSent"

3. DiscountService: проверьте, получают ли они скидку за своевременную оплату, затем отправьте "CustomerCanGetPaymentDiscount"

Если все три сообщения сработали для одного и того же PAIDBILL: Сообщение "PaymentPosted", "CustomerPaymentEmailSent", "CustomerCanGetPaymentDiscount", тогда я хочу отправить клиенту электронное письмо, чтобы они получили скидку на следующий счет. Это должно быть сделано ПОСЛЕ того, как все трое подверглись поражению, и порядок не имеет значения. Как мне запланировать отправку нового сообщения "EmailNextTimeDiscount", без необходимости опрашивать, какие сообщения срабатывают каждую минуту, час, день?

Все, что я могу придумать, - это иметь таблицу SQL, которая отмечаетчто каждый из них завершен (путем блокировки таблицы), и когда последний заполнен, отправьте сообщение. Это было бы хорошим решением? Я нахожу это антишаблоном для микросервиса и дизайна очереди сообщений.

Answer 1

Если вы используете сообщения (например, Service Bus / RabbitMQ), то я думаю, что решение, которое вы описали, является лучшим. Этот тип дизайна - когда службы обладают знаниями о других доменах в системе - обычно называется хореографией.

Вы захотите выбрать сервис, который будет отвечать за эту бизнес-логику. Эта служба должна будет получать все предыдущие типы сообщений, чтобы она могла определить, когда (если) все они были выполнены, что, вероятно, она хочет сделать, записав, какие ворота уже прошли в базе данных.

Одна из альтернатив, которую вы могли бы рассмотреть, - это связывание бизнес-процессов вместо параллельного выполнения. Итак ...

1. PAYBILL заставляет FinanceService дебетовать бухгалтерскую книгу и запускать "PaymentPosted"
2. "PayentPosted" заставляет EmailService отправлять электронные письма Клиенту, который поблагодарил вас за оплату счета и передает "CustomerPaymentEmailSent"«
3. « CustomerPaymentEmailSent »заставляет DicsountService проверить, получают ли они скидку за своевременную оплату, а затем отправляет« CustomerCanGetPaymentDiscount »
4. Электронное письмо, которое вы хотите отправить, только что инициировано« CustomerCanGetPaymentDiscount ».

Если честно, я бы переключился на модель зависимости, которую вы используете на этом последнем этапе. Таким образом, вместо того, чтобы какой-либо компонент прослушивал события «CustomerCanGetPaymentDiscount» из DiscountService и отправлял электронное письмо, я думаю, что вместо этого DiscountService скажет другому компоненту отправить электронное письмо. Мне кажется естественным для чего-то, что рассчитывает скидки, чтобы знать, что электронное письмо должно быть отправлено. Это кажется менее естественным для того, что отправляет электронные письма, чтобы узнать о скидках (и все остальное, что требует отправки электронных писем). Вот почему мне не нравятся архитектуры, в которых предполагается, что каждое сообщение должно быть событием, а каждое действие должно инициироваться событием: оно устраняет множество решений о том, где может жить логика домена, потому что получатель сообщения всегда должензнать о домене отправителя сообщения, а не наоборот.