Если я правильно понял, то смысл в том, что каждый контекст решает что делать с теми или иными данными, которые ему передаст другой контекст. Т.е. в моем примере контекст "Расчет цены", должен передать цену в контекст "Профиль" и уже именно профиль решает, накинуть скидку за ДР или нет. Думал об этом варианте, так как он проще нежели синхронизация данных, тем более если делать без микро на разных машинах.
Но разве это не грубо RPC c его минусами в виде жесткой зависимостей сервисов друг от друга? Отвалился один - отвалилась вся система рассчета цен.  Ну или в рамках контекстов - развязывали, развязывали - а потом связали за счет публичного api этих контекстов, которые они дергают друг у друга.
Ну или я не понял видео :(

ты досмотрел до rules engine?

Да, мои выводы сделаны по пайплану идущему дальше в видео. Хотя конкретно про rules engine не особо понял

вообще это все к бизнесу вопрос. Допустим у тебя ДР 4-ого ноября. Ты положил товар в карзину 3-его ноября и аккурат в полночь перешел на чекаут. Ты уже расчитываешь на скидку?

Или другой кейс - ты положил товар в карзину в 23:59 4-ого, и у тебя еще действует скидка. Мы когда после 00 перейдем у нас все еще скидка действует?

Или третий кейс - я купил 4-ого товар со скидкой и на след день поменял свой ДР на 5-ое число. Я так могу наебывать твою систему?

он вроде там говорил про простейший цикл, где перебираешь функции и получаешь результат из одной, отправляешь его в другую
я так это понял

Да, функция = вызов api другого контекста

ну не совсем. Ты тип бродкастишь в системе сообщение "надо посчитать скидос" и разные контексты могут каждый кинуть свои сообщения с уже посчитанными правилами. То есть контекст который владеет "датой рождения" не дату рождения будет отправлять а "{birtdayDiscountApplicable: true}". Дальше уже твой рулс эджинг все эти штуки соберет и по своим правилам посчитает нужную скидку

все взаимодействие происходит асинхронно в его схеме (саги) и при этом контексты данные сами не выпускают

а, ну этот рул энжин - это ещё одна сага по ходу

да, просто на вход ей какие-то предикаты а на выходе результат

ну да, так уходим от централизации.

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

на примере с fraud detection оно лучше

Так, вариант с асинхронщиной, интересно. Я этого не понял по видео, думал синхронно.

очки - это получается абстракция такая, часть интерфейса чтоли. Обобщение для удобного интерфейса 🤔

Или это уже больше детали реализации и сложности  проекта синхронно/асинхронно?

Вся суть что нам возвращается не дата, а готовая скидка / чек что скидку нужно сделать?

например. вот у тебя чел там добавляет штуки в карзину добавляет их и тд. На все это у тебя есть ивенты. Чел там выбирает какой-нибудь адрес доставки другой и т.д.

А в фоне у тебя все это дело будет раскидывать ивенты по контекстам. Контекст которыйз нает что ты покупал сравнивает цены товаров или характеристики. Мол если ты много книг покупал странно что ты начал скупать ноутбуки за тысячи баксов. Этот контекст отправит нам в ответ сообщение обратно мол "скор подозрений на основе покупок - 10". А другой контекст который знает куда доставлялись предыдущие товары глянет нет ли тут наебки - есть - повышаем скор.

А рулс энджен все эти ивенты словит и просто просуммирует. Причем для каждого "источника" мы еще можем веса задавать - и это уже рулс энджен знает.  И такие можем принимать решение надо чуваку еще двухфактору какую сделать или подтверждение владения аккаунтом или нет.

При этом если какой из сервисов упадет - мы не будем дожидаться ее оценки и сделаем выводы по тому что есть.

при этом сам процесс фрауд детекшена мы можем запустить сразу как чел зашел на сайт, можно накапливать информацию о каждом пользователе и сбрасывать скоры только если он подтвердил владение аккаунтом к которому карточка привязана

в любом случае в твоем конкретном кейсе с датой рождения меня оч смущает возможность наебать систему