это прикол, я надеюсь)
У тебя сейчас описано 3 абсолютно разных юзкейса с 3 разными доменами. Создать юзера — User Создать заказ — Order Отправить уведомление — Notification. Или я не понимаю что ты имеешь в виду
ок. начнем с начала. на фронте, аноним набрал корзину, нажал кнопку оформить заказ. что надо сделать: 1. зарегать чувака 2. создать заказ 3. отправить в логистику 4. отправить уведомление расскажите как все будет, начиная с фронта
А регаем по какому признаку ? Он ввёл нам свой номер или какие-то данные ?
да да, все данные есть и у нас монолит должно быть интересно)
Транзакцию в контекст и добрый вечер 😁
тут парни говорят что нет сценариев на бекенде и домены не пересекаются никогда и нигде
вот
Поставлю брокера и консюмеров в 1 монолит
Ну в монолите и в сервисах это в итоге по разному решается, с евеншуал консистенси в монолите я не развлекался
и никто не развлекается. потому что задачи монолита совершенно другие
Всё очень просто: Во-первых, регистрации идёт по отдельному эндпоинту, и уже зарегистрированным он отправляет запрос на заказ Во-вторых дёргается usecase CreateOrder, который отправляет событийные уведомления в модуль/микросервис логистики и в модуль/МС уведомлений.
бизнес требование: нет юзера - нет заказа либо все вместе создается, либо никак да, это просто транзакция
Из фронта будет два запроса, один на регистрацию, другой на заказ
ну вы же понимаете все + и - это решения? ну ладно, а транзакционность как реализовать?
Транзакционность при нескольких доменах очевидно никак, только BASE
Твой как сделан через создания комка
Тогда непонятно какой смысл в доменах если каждый лезет в кишки друг-друга
мой как приносит бабло бизнесу а уж комок это или нет, зависит от реализации
каждый не лезет никуда, есть сценарии, эти сценарии берут домены и управляют ими
Вероятно это не домены, а просто агрегаты
еще один термин)
Обсуждают сегодня