Size: a a a

Software Design/Architecture/Zen

2021 May 06

Д

Дмитрий in Software Design/Architecture/Zen
Маленький водомёт - герой дня!
источник

VS

Vlad Sobenko in Software Design/Architecture/Zen
Я бы предложил тебе вместо того, чтобы тратить всё время на рисование пдфки - попробовать переписать всё с нуля через тдд.
Получится нормальные тесты, большое их количество, удобный интерфейс.
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
В UML есть отношение агрегат и композит. "Сожержит" и "состоит из". А вообще это слово ну уж слишком оверюзед особенно в этом чате. И смысла у него не больше чем у сочетания "просто какая-то штука"
источник

АГ

Алексей Гевондян... in Software Design/Architecture/Zen
вспомнилась песня любэ ты агрегат дуся на 100 киловатт)
источник

VS

Vlad Sobenko in Software Design/Architecture/Zen
Мне кажется она более отчётлива. - Стейтфул штука с поведением.
И чатом рекомендуется иметь много маленьких таких на каждый юзкейс хотя бы по одной.
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Приветствую :) Подскажите в какую сторону читать.  
Есть простой сценарий:  Списывание с баланса пользователя, коммит, ивент "Заказ оплачен" в кролика, перехват ивента с  установкой заказу статуса "оплачен".
На каком-то этапе после коммита в БД - ошибка, т.е. с баланса деньги списались, а заказ остался "не оплачен".
Я так понимаю, это сагами разруливается? Если да, есть мб у кого то какие то ссылки на пример кода как они примерно выглядят. По теории самого паттерна не особо понятно, как готовить код. А если не саги - то чем разруливать? :)
источник

˸A

˸̧̨ ͅBlack Akula˸̧̨ ... in Software Design/Architecture/Zen
А какая ошибка бд? И как часто происходит?
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Не ошибка БД, а после коммита в БД. Чуточку подправил текст.
Вопрос теоретический , а не из проекта.
источник

˸A

˸̧̨ ͅBlack Akula˸̧̨ ... in Software Design/Architecture/Zen
Условно, если ошибка встречается раз в 5 лет, то дешевле вручную обрабатывать, чем писать велосипед
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Звучит здраво. Меняем условие задачи - ошибка не раз в 5 лет, ее нужно обработать и откатить баланс пользователя. Например кролик сдох и мы потеряли часть данных. Т.е. ивент вообще даже не дошел.
источник

T🐜

The Ant 🐜 in Software Design/Architecture/Zen
взять вместо кролика что-то другое :D
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Не, ну можно ивент бросать в локальный евент диспатчер, и все обернуть в транзакцию :) Это понятно )
источник

T🐜

The Ant 🐜 in Software Design/Architecture/Zen
Я имел в виду более надежный инструмент. Кролик проблемный, это всем известно.
А еще параллельно логируешь каждое действие, как в отдельную бд так и в файлы. Если чо руками все равно можно разрести.
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Более/менее - проблема всегда возможна. Потом ручками гемор, еще больше можно накуралесить.
источник

AL

Anton Lakotka in Software Design/Architecture/Zen
саги. и там все относительно просто.

сага ОплатаЗаказа:
1. Отправить команду: Списать со счета
1.1 Получить ивент: Деньги списаны -> Шаг 2
1.2 Получить ивент: Денег нет -> Закрыть сагу (или отпарвить любую другую команду)

2. Отправить команду: Подтвердить оплату заказа
2.1. Получить ивент:  Заказ подтвержден -> Закрыть сагу. и отправить окончательный ивент "Заказ Оплачен"
2.2 Получить ивент: Ошибка подтверждения -> Шаг 3

3. Отправить команду: Вернуть деньги
3.1 Получить ивент: Деньги возвращены -> Закрыть сагу и отправить окончательный ивент "Заказ не оплачен: причина такая-то"
3.2 Получить ивент: Ошибка возврата -> Повторить 3 с таймаутом или любая другая стратегия ошибки.

все это можно описать 1-м классом и протестировать все возможные сценарии.
а потом просто внедрить куда следует.

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

ПГ

Павел Г. in Software Design/Architecture/Zen
Спасибо, очень развернуто! :)
А если например какой то ивент просто затерялся? Или ошибка вылетела, после которой ивент "ошибки" не сгенерился?
Есть какие то сценарии по запуску саги вручную? Типа по крону или еще что-то
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
И выходит под каждую транзакцию нужно делать новую сущность саги?
источник

AL

Anton Lakotka in Software Design/Architecture/Zen
Есть. Просто таймауты и ретраи.
источник

AL

Anton Lakotka in Software Design/Architecture/Zen
Под каждую сложную транзакцию, да. Т.е. где несколько шагов, которые не совсем помещаются в 1 транзакйию БД
источник

AL

Anton Lakotka in Software Design/Architecture/Zen
источник