SP
Size: a a a
2021 February 02
AB
Эм, ну, валидируются входящие данные от внешних систем, от пользователей. Ибо они как раз и могут пытаться “чего попало” возможно даже специально передевать. А внутри смысла обмазываться валидациями нет. Соотв. если каждый сервис отдается пользоватлю - в смысле доступен извне прям из кода условного сайта, то большой вопрос вообще зачем так делать, а не иметь некий гейт в свою систему и там будут определенные проверки.
SP
ты можешь периодически чекать свои данные на предмет мусора и вычищать говно
AZ
А например доставка с ID заказа которого нет вообще и таких 100 ?
Ну я не оч разберусь, откуда такие неконсистенные данные появляются? Если ты сейчас про секурность, то это тема для другого разговора
AZ
Подписывай формочку csrf токеном заказа, не знаю)
ПГ
Спасибо, почитаю :)
AB
Считай как тебе в контору закинули накладную без оплаты. Ну ок, пусть валяется, делов то
Вот на входе накладную и оплату и проверили, а внутри системы сто проверок не то чтобы еще раз нужны.
ПГ
Подписывай формочку csrf токеном заказа, не знаю)
Ну банально меня напрягает, что я могу отправить запрос на доставку и он сохранится, а в БД такого id заказа нет.
AB
Потому логично и разумно валидировать данные приходящие от пользователя. А если данные уже внутри системы между сервисами гоняются, то смысла в fk не то чтобы может оказаться дофига и вообще нужно подумать зачем (а не просто страшная неизвестность)
ПГ
Потому логично и разумно валидировать данные приходящие от пользователя. А если данные уже внутри системы между сервисами гоняются, то смысла в fk не то чтобы может оказаться дофига и вообще нужно подумать зачем (а не просто страшная неизвестность)
Так вот и вопрос был. Они приходят от пользователя. ID одного контекста, который надо сохранить в другом.
AB
Тут походу каждый сервис как бы и независим, но пользователь имеет возможность всё это напрямую дергать, но зачем?
AZ
Ну банально меня напрягает, что я могу отправить запрос на доставку и он сохранится, а в БД такого id заказа нет.
Заказ наверное ближе к long-running process'у, с разными этапами типа pending waiting paid delivered. Cама по себе запись в доставке не должна появляться по запросу - она ж является результатом предшествующих бизнесс-процессов, юзер может сделать "запрос на доставку", а уж как дальше там пойдет - зависит от твоих бизнес-правил. Сам по себе запрос юзера на доставку можно не валидировать
ПГ
В целом, наверное, второму контексте вообще должно быть пофиг, валидный это ID или нет - не его зона ответственности. Но меня напрягает после обычного подхода с FK/ предварительнйо проверкой наличия заказа в базе.
AB
А зачем вы пытаетесь так всё разбить? Микросервисы?
ПГ
Заказ наверное ближе к long-running process'у, с разными этапами типа pending waiting paid delivered. Cама по себе запись в доставке не должна появляться по запросу - она ж является результатом предшествующих бизнесс-процессов, юзер может сделать "запрос на доставку", а уж как дальше там пойдет - зависит от твоих бизнес-правил. Сам по себе запрос юзера на доставку можно не валидировать
Ну а если 2 формы? Или доставка оформляется позже.
ПГ
А зачем вы пытаетесь так всё разбить? Микросервисы?
Монолитит, но попытка разбить на контексты максимально приблидженные к микро
AZ
Ну а если 2 формы? Или доставка оформляется позже.
2 формы чего?
ПГ
2 формы чего?
1) Создание заказа.
2) оформление доставки. Например после его готовности через день.
2) оформление доставки. Например после его готовности через день.
AZ
1) Создание заказа.
2) оформление доставки. Например после его готовности через день.
2) оформление доставки. Например после его готовности через день.
Подписывай формочку доставки токеном заказа с сикректсом на сервере, не знаю) Если так левые записи напрягают
AB
Монолитит, но попытка разбить на контексты максимально приблидженные к микро
Тогда если есть FK, то зачем их лишаться? Микро - это просто вариант распределенной системы, нормальный монолит нормально работает. Но действительно нужно неплохое разделение на контексты, например.