сообщений, есть сервис платежей. Платёж падает и посылает ивент paymentFailed
В сервисе уведомлений создаётся консьюмер, который слушает информацию о платежах, и создаёт сообщение. Проблема в том, что есть другие события, которые тоже требуют создания сообщений, и в итоге сервис начинает знать о куче вещей из других доменов
При этом использование команд, например, переворачивает всё наоборот (платежи знают о сообщениях)
Есть смысл писать какой-то сервис-адаптер, который послушает ивент от пейментов и пошлёт команду в сообщения ?
ну как раз саги/бизнес-процесс менеджер в простом виде как раз про это есть бизнес прцоесс: разослал в домены команды, слушает события и если что — делает откаты (компенсирующие действия, если где-то упало, то откатить др домены (отменить заказ например, если оплата не прошла как абстрактный пример — это отправить новую команду на отмену) или переходит к след шагу
А без саг ? Они у нас считаются оверинжинирингом )
без саг: простая сущность бизнес-процесса, он работает с несколькими доменами — не в доменах же логику завязывать на др домены итого: - есть десяток контекстов - есть еще один контекст, в котором описана работа с нескольькими, довольно удобно в одном месте сборная солянка как работать с несколькими (отправил команду оплатить, отпарвил команду забронить товар, отправил сообщение на почту)
Ну это уже хореографическая сага какая-то
https://youtu.be/Fuac__g928E
Давай думать. Есть как ты сказал 2 решения влоб - либо все сервисы знают о нотификашках либо нотификашки слушают кучу ивентов и по ним пытаются понять чё делать. Дальше думаем что ещё страшного мы можем придумать. Скажем в нотификашках должен быть какой-то контент. Откуда он возьмётся? Сервису нотификаций надо будет ещё больше знать о других сервисах? Вообще в чем задача "сервиса нотификаций" - у этого сервиса есть некие топики, есть ресипиента, их настройки нотификаций, кому на email кому пуш на мобилку кому sms. Допустим на каждую большую фичу нас просят интегрировать нотификашки. Если брать решение влоб то это много зависимостей между командами. Можно сделать абстрактный контракт который позволяет зарегистрировать новый топик. В этом случае все сервисы знают про нотификашки но контракт у нас стабильный, есть дока и мы не блочим работу команды. Скажем есть админка где все можно настроить и не дергать разработчиков. В этом ключе связанность не такая большая и не является проблемой.
ну это не совсем нотификации, скорее внутрненние тикеты. т.е. сервис знает там об агентах и как создавать тикеты на них, а остальные сервисы сейчас дергают по хттп его апи для создания этих самых тикетов причем по апишке уходит вот как раз вся информация, которую по идее другим продуктовым сервисам вообще знать не нужно: на кого создавать, на какие группы агентов, для каких регионов, какой темплейт в сообщении использовать. итого там около полутора десятка различных параметров. кажется, что это хуже, чем если бы сервис тикетов подписывался на нужные ивенты (пусть их было бы даже и много), т.к. в противном случае при изменении контракта тикетинга придется пойти и перефигачить десятки - сотни мест в других сервисах, где эта апишка вызывается (синхронно или асинхронно) а так все изменения будут локализованы + при изменении контракта внешнего сервиса нужно будет сходить всего в 1 место и поправить там (хотя это тоже лишние коммуникации между командами, что не есть гуд)
это вопрос стабильности контрактов. Условно, какие данные нужны, у кого они есть... может быть решение будет не идеальным с точки зрения связанности но если скажем добавлять новые такие ивенты нужно раз в пару месяцев и это не сказывается на деливери особо - ну почему нет. тут как бы нет правильно неправильно. Вопрос стоимости.
Обсуждают сегодня