AI
да, от задачи зависит. если у тебя долгоиграющая операция, то не может, очевидно. если нет - то может
Size: a a a
2021 July 15
ИЛ
некоторые приватами обмазываются как не в себя, забывая, что важны не приваты, важно, когда работа только в сценариях, а вне сценариев нет
DT
А как же тот факт, что полиси для записи совершенно не похожи на политику для чтения?
SP
Ну это не про cqrs
SP
Вьюшкам в базе много лет как бы
SP
Грег же cqrs по сути под es придумывал
HH
"Не должны фейлится из за бизнес операций"
А то что потом приходит условный имейл с извинениями - это не фейл? Чет не догоняю разницы
А то что потом приходит условный имейл с извинениями - это не фейл? Чет не догоняю разницы
SP
Разница в том что если у тебя 99.9% команд завершаются хорошо не надо заставлять пользователя ждать
DT
ну дык, чем же это не CQRS? модели для чтения и для записи по факту разные
SP
В том как ты модели строишь
AI
короче, мне видится, что тут есть два лагеря, и для каждого лагеря понимание другой стороной cqrs не верно
DT
штуки придуманные для одного часто находят применение в других местах, парадокс Тесея какой-то получается
AI
ну а откуда ты узнаешь, что они завершатся хорошо ? Ну вот у тебя в базе канкаренси токен дал отсечку, валидация бд не прошла, коннект отвалился
AI
если это не шедуллинг, то не информировать юзера о результате - опасно
SP
Есть лагерь Грега - он урощает cqrs до "делай как хочешь"
Есть лагерь уди - он топит за то что бы cqrs был более конкретным и применялся строго там где от него есть толк
Есть лагерь уди - он топит за то что бы cqrs был более конкретным и применялся строго там где от него есть толк
SP
Кто говорит о том что пользователь не будет информирован? Весь вопрос только когда
AI
бизнес говорит, например
DT
тут речь про асинхронность больше
DT
ендкастомер дергает ендпоинт, получает 200 ОК, тебя понял, твою команду принял, ожидай информирования
SP
Ну может им не нужен cqrs :)