AK
Size: a a a
2021 March 18
КГ
почему бы не сделать все необьходимые изменения в бд сразу, в рамках одного запроса, а не догоняться потом в евентах, которые могут выполниться после
Например потому что ряд операцией требует времени, и пользователю который ждёт ответ от сервера нет никакого смысла дожидаться их?
Например потому что надо сходить во внешний сервис, и если сервис не отвечает, то повторить запрос через 5-10-20-40-60с?
Например потому что надо сходить во внешний сервис, и если сервис не отвечает, то повторить запрос через 5-10-20-40-60с?
ПГ
Например потому что ряд операцией требует времени, и пользователю который ждёт ответ от сервера нет никакого смысла дожидаться их?
Например потому что надо сходить во внешний сервис, и если сервис не отвечает, то повторить запрос через 5-10-20-40-60с?
Например потому что надо сходить во внешний сервис, и если сервис не отвечает, то повторить запрос через 5-10-20-40-60с?
Такие операции кидаются потом в бас. А которые нужны синхронно - нет. Больше гибкости, но и больше грязи :(
AD
почему бы не сделать все необьходимые изменения в бд сразу, в рамках одного запроса, а не догоняться потом в евентах, которые могут выполниться после
потому что:
1) реакция на событие может повлиять на результат (сломанная транзакция)
2) влияет на время выдачи ответа, когда реакция не обязана сразу отработать (иначе это часть основной операции)
3) далеко не всегда будет возможность ограничится тем же хранилищем - тебе понадобится отправить письмо и всё - нарушение консистентности наступает на пятки
1) реакция на событие может повлиять на результат (сломанная транзакция)
2) влияет на время выдачи ответа, когда реакция не обязана сразу отработать (иначе это часть основной операции)
3) далеко не всегда будет возможность ограничится тем же хранилищем - тебе понадобится отправить письмо и всё - нарушение консистентности наступает на пятки
ПГ
потому что:
1) реакция на событие может повлиять на результат (сломанная транзакция)
2) влияет на время выдачи ответа, когда реакция не обязана сразу отработать (иначе это часть основной операции)
3) далеко не всегда будет возможность ограничится тем же хранилищем - тебе понадобится отправить письмо и всё - нарушение консистентности наступает на пятки
1) реакция на событие может повлиять на результат (сломанная транзакция)
2) влияет на время выдачи ответа, когда реакция не обязана сразу отработать (иначе это часть основной операции)
3) далеко не всегда будет возможность ограничится тем же хранилищем - тебе понадобится отправить письмо и всё - нарушение консистентности наступает на пятки
Почему основная операция (которая в запросе) не может быть как совокупность агрегатов/(чего угодно) которые общаются через ивенты?
КГ
Такие операции кидаются потом в бас. А которые нужны синхронно - нет. Больше гибкости, но и больше грязи :(
Я не оч понимаю как вы там это готовите, у меня когда messageBus появился с диспетчером симфы пользоваться перестал
AK
потому что:
1) реакция на событие может повлиять на результат (сломанная транзакция)
2) влияет на время выдачи ответа, когда реакция не обязана сразу отработать (иначе это часть основной операции)
3) далеко не всегда будет возможность ограничится тем же хранилищем - тебе понадобится отправить письмо и всё - нарушение консистентности наступает на пятки
1) реакция на событие может повлиять на результат (сломанная транзакция)
2) влияет на время выдачи ответа, когда реакция не обязана сразу отработать (иначе это часть основной операции)
3) далеко не всегда будет возможность ограничится тем же хранилищем - тебе понадобится отправить письмо и всё - нарушение консистентности наступает на пятки
какое письмо то в транзакции, камон?
КГ
письмо да, это уже постфактум, а если ты делаешь логгирование жизненных циклов сущности? не проще ли сделать это в одной транзакции? как минимум надежнее и данные консистентны всегда
А причём тут логирование и доменные ивенты?
КГ
логгирование в таблицу бд
когда сущность была создана, когда удалялась, когда изменялась
когда сущность была создана, когда удалялась, когда изменялась
Для этого доменные ивенты не нужны
ПГ
Для этого доменные ивенты не нужны
Да и это тоже кстати) просто исторяи сущности как релейшен
КГ
Точнее EntityUpdated и EntityDeleted это не доменные ивенты
ПГ
Точнее EntityUpdated и EntityDeleted это не доменные ивенты
А чьи?