и иногда получается красивый выразительый код

задача этого результата отменить что то в бд и тд

может быть и sleep можно и без sleep сделать

но я потом отказался от этих объектов

не стал делать слишком абстрактную штуку

сделал более конкретную

верней от них не отказался просто они стали чуть другими

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

ну у меня в голове крутились идеи, что например если надо какие-то еще действия совершать как единую транзакцию, их можно было бы как-то зашить в объект результата. ну типа result.notifyAdmins(emailSender)

ммм.... саги?

и объект результата не нужен)

ммм.... саги?

ну саги это крупномасштабная штука

ну саги это крупномасштабная штука

ну в первом приближении, не особо

почему?

мы тут про более мелкие вещи говорим, как мне кажется

но смысл да, такой

если не обмазываться всякими басами, довольно простая и лёгкая

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

вот да, Саги это не сложно, во всяком случае не с технической точки зрения.

короче идея - делать последовательность действий в зааисимости от результата предыдущего действия, инкапсулировать эту логику где-то. почему бы и не в объекте "резальтат операции"

определение саги ж в чистом виде

да хоть что

ток объект результата там лишний по сути)

пусть саги. очередное имя для старой идеи

ток объект результата там лишний по сути)

да.

убираем "результат", оставляем "операция"

ну сагу проще всего представить как обычную транзакцию) либо всё ок, либо возвращаем взад всё, что изменили)

ну сагу проще всего представить как обычную транзакцию) либо всё ок, либо возвращаем взад всё, что изменили)

ну у нее же все равно какой-то результат есть :)

и нам этот результат надо фронту отдать

ну у нее же все равно какой-то результат есть :)

событие какое-то, например :) типа "я закончила")

а

ок ок

и нам этот результат надо фронту отдать

CQS же

не отдавать ничего фронту, пусть он спросит еще раз

CQS же

дада

я понял

не отдавать ничего фронту, пусть он спросит еще раз

тут должна была быть реклама центрифуги)

не ну сокеты еще подрубать... зачем

хотя можно

чорд) не угадал) мне казалось, что ты за неё накинешь) но, видимо, устал уже)

а если фронту надо знать ПОЧЕМУ не получилось, как быть?

событие "ни шмагла")

событие "ни шмагла")

асинхронно приходит во фронт?

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

но, опять-таки, что мешает хранить стеит и по твоей логике спросить ещё разок?)

но, опять-таки, что мешает хранить стеит и по твоей логике спросить ещё разок?)

pull вместо push?

pull вместо push?

ну тип того

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

блин) тебе шашечки, или ехать?) конечный смысл не особо зависит от реализации) хочешь стильно и молодёжно - центрифуга твой выбор)

блин) тебе шашечки, или ехать?) конечный смысл не особо зависит от реализации) хочешь стильно и молодёжно - центрифуга твой выбор)

так это вообще не я накинул изначально )

так это вообще не я накинул изначально )

не обращай внимания) у меня просто триггер на саги)

как всегда ответ получается: делай как хочешь, все равно где-то наебешься

как всегда ответ получается: делай как хочешь, все равно где-то наебешься

ну на самом деле штука довольно мощная. И в то же время простая

ну сагу проще всего представить как обычную транзакцию) либо всё ок, либо возвращаем взад всё, что изменили)

Это как в миграциях down ?

а уж на сколько ты упорешься в реализации - детали

Это как в миграциях down ?

ага

Нигде не видел чтобы его юзали

Может просто плохой опыт у меня

Но иногда довольно сложно поддерживать транзакционность

в тех же сагах у тебя есть 2 варианты работы: 1) ты можешь эмулировать транзакцию 2) ты можешь не изменять реальные данные до самого конца, а если всё ок по цепочке - выполнить то, что хотел. в первом случае ты эмулируешь транзакционность, во втором - некое подобие агрегированной операции. Второй вариант проще

Как например быть если после блокировки денег у пользователя их разблокируют через 15 дней?

если ещё проще, то сага - блок-схема.

Не юзал саги

шедьюлер)

Киньте ссылку

Ото кажется я их переизобретаю у нас на проекте

У нас есть много фоновых задач в том числе и типов этих задач

Киньте ссылку

http://microservices.io/patterns/data/saga.html

И они сильно зависят от кучи внешних сервисов апи которых могут глючить

Спс

все идея в компенсации изменений

Как например быть если после блокировки денег у пользователя их разблокируют через 15 дней?

а ты имеешь контроль за этим?

ну то есть ты попросил агрегатор заблокировать часть средств на какой-то промежуток времени

и деньги взяли и разблокировались - мне кажется это вопрос не транзакционности

Так hold и разблокировка холда может занимать время

ну там придёт событие, что холд снят на колбек урл

До 15 суток вроде

До 15 суток вроде

меньше обычно

Так пользователю это сложно объяснить

меньше обычно

Обычно да

но есть и обратная сторонав медали: то, что холд снят не означает, что бабло вернулось

если быть точнее, анлокнулось.

так что сия затея кодом не покрывается. По крайней мере я таких вариантов не видел. Хотя и кой чего понимаю в платёжках

Ну да согласен

Просто юзверям сложно объяснить

Они обычно смотрят банке

А банк операции процессинга с задержкой накатывает

ну в конечном счёте объяснять сие юзерам - не задача программиста) так что хз чего ты паришься)