Задать вопрос

Доменные события, как их реализовать без использования сервисной шины?

Допустим, мое приложение очень критично к консистентности данных и такая вещь как распределенные транзакции с этими всякими сагами и 2pc мне не нужно, а сам я полагаюсь на ACID, предоставляемый моим СУБД.

В моей системе есть 2 бок-о-бок идущих события
Регистрация преподавателя ведет за собой обязательную отсылку Emailа на зарегистрированный адрес
И поскольку в этом письме содержатся данные для входа (логин и пароль), то письмо должно быть обязательно доставлено
Опустим момент проблем с реализацией писем провайдером

Есть 2 пути
1) публикация события
2) сохранение сущности письма в БД, а затем его обработка в асинке

с первым есть конкретные проблемы в плане реализации - пользовался библиотекой Prism.EventAggregator, очень удобная вещь, но у нее минус - она для фреймворка, для .NET 5,6,7 ее нет.
второй момент - по-хорошему публикация уведомлений не должно ломать основную логику, потому pubsub сюда вписывается как нельзя кстати. Но это письмо - исключение, поскольку оно обязательно должно быть обработано и доставлено, с circuit-breakingом или без - неважно. Без влияния внешних факторов процесс должен завершиться положительным исходом

2) тут все проще. Основную сущность как и письмо добавляем используя транзакцию, что уже выглядит достаточно... надежно(?). Но вот обработка этих писем... Не хочу костылить с триггерами, т.к нет даже официальной либы на нагете от майкрософта для EFа + они vendor-specific... хотя вариант очень привлекательный был.
Второй простой вариант - backgroundservice (aka hosted). Но тут я столкнулся с тем, что этот сервис ни что как long pollng базы. А мне нужно сохранять хотя бы инфраструктурную производительность.
Поэтому суть моего вопроса такова:
возможно ли выполнить реализацию persistent событий, используя свою БД, но не прибегая к написанию сервиса, задействуя шину, брокера и т.д. и при этом не использовать long polling к базе?
В будущем мне этот сервис с сообщениями вообще не вписался и просто будет висеть лишним процессом. Письмо с данными о регистрацией - грубо говоря единственное. Ради него добавлять в проект еще один сервис, настраивать шину (да даже если по http)... вообще нет желания
  • Вопрос задан
  • 134 просмотра
Подписаться 5 Простой Комментировать
Пригласить эксперта
Ответы на вопрос 1
@forced Автор вопроса
Сидел рассматривал EntityFramework.Triggered. 63adc742143c1651136394.png
При юзании транзакции - тригер на скрине сработает дважды.
А тригеры по типу IAfterCommitTrigger у меня вообще не работал... какая-то сырая что ль либа была, без понятия
Вопрос актуален до сих пор.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы