ЕР
Не нужно копипастить модель ордера в модель юзера т.к. там одно поле нужно
Size: a a a
2020 February 12
В
Обратный эффект. ООпшники ворвались
Oℕ
Я могу тебе лишь всё тот же доклад накинуть )
https://www.youtube.com/watch?v=hev65ozmYPI
https://www.youtube.com/watch?v=hev65ozmYPI
А рассказать сам можешь?
ЕР
Анемик = общий мутабельный стейт
Oℕ
Я могу тебе лишь всё тот же доклад накинуть )
https://www.youtube.com/watch?v=hev65ozmYPI
https://www.youtube.com/watch?v=hev65ozmYPI
как обойтись без пересечений данных, если нужно перед посылкой в сервис проверить данные, или из кеша взять данные оффера, чтобы не ходить
ЕР
как обойтись без пересечений данных, если нужно перед посылкой в сервис проверить данные, или из кеша взять данные оффера, чтобы не ходить
Oℕ
а спасибо
Oℕ
всё время забываю
ᛒ
@aleksei_t кароче ору, заказал куклу из японии, дороже лимита конечно, едет через емс, ну и кароче начал выяснять как пошлину заплатить т.к. она уже в рф, мне говорят - дак курьеру наличными заплатишь, ордер таможенный оплатишь и все
ЕР
как обойтись без пересечений данных, если нужно перед посылкой в сервис проверить данные, или из кеша взять данные оффера, чтобы не ходить
Можно обойтись и с пересечениями, не нужно до абсурда доводить
(
Анемик = общий мутабельный стейт
объясните мне, каким образом?
DE
у тебя бизнес процесс - пользователь заходит в личный кабинет, нажимает кнопку, у него процесс, который помимо прочего должен согласовать ордер
Если факт согласования в сервисе юзера хранить не нужно, то из гейтвея можно прямо отправить в сервис ордеров approve(userId).
Если же и там, и там хранить нужно, то у юзера храним только ID заказа и статус, а процесс производим эвентами через очереди. Так друг к другу напрямую ходить не будут.
Если же и там, и там хранить нужно, то у юзера храним только ID заказа и статус, а процесс производим эвентами через очереди. Так друг к другу напрямую ходить не будут.
ЕР
объясните мне, каким образом?
Ты делаешь структуру данных и разные сервисы её мутируют через геттеры-сеттеры
w
Ты делаешь структуру данных и разные сервисы её мутируют через геттеры-сеттеры
Oℕ
Можно обойтись и с пересечениями, не нужно до абсурда доводить
Но если у тебя есть одна модель с действиями, которые выражаются в сохранении в очередь или там в базу
И вторая модель с действиями, которые выражаются в отсылке запроса или очередь в первый сервис
И вторая модель с действиями, которые выражаются в отсылке запроса или очередь в первый сервис
ЕР
объясните мне, каким образом?
Анемичная модель = структура данных по сути
Oℕ
Значит - это разные модели
Oℕ
И они описывают одни данные разным способом, так?
ЕР
Но если у тебя есть одна модель с действиями, которые выражаются в сохранении в очередь или там в базу
И вторая модель с действиями, которые выражаются в отсылке запроса или очередь в первый сервис
И вторая модель с действиями, которые выражаются в отсылке запроса или очередь в первый сервис
Модель с действиями = модель которая в базу сохраняется