Kirill
ебашь в роутах весь код и вуаля
Павел
юзкейс вызывать из юзкейса - это какое-то говно не правильно.
юзкейс у тебя дергает домен с его логикой и доменными событиями. А в конце флашит.
Либо дергает сервис, который что-то вычисляет.
В твоем примере про множественное редактирование, юзкейс вызывает update у домена Post, внутри которого вызываются все необходимые доменные события, которые обрабатываются после флаша
Ну спорно. Например 2 модуля, юзкейсы - это границы модуля. Один модуль должен вызывать или получить данные из другого. Не всё строится на асинхронщине и ивентах. Вот и вызов юзкейса из другого юзкейса.
Или например был кейс: есть юзкейс создания заказа, а потом пришел заказчик и сказал - хочу атомарную регистрацию при создании заказа незареганным пользователем. Т.е. любая ошибка должна не создавать ни заказ, ни юзера.
По сути был юзкейс CreateOrder а потом создан юзкейс дополнительный, который его вызывал под транзакцией общей - RegisterWithCreateOrder. Почему нет?
Павел
ебашь в роутах весь код и вуаля
Вот да, лишь бы работало и не мешало развиваться. Короче не все однозначно как порой кажется.
Kirill
но тут надо разделять, у тебя хелло ворлд на пару методов или монолит сто в одном)
Павел
но тут надо разделять, у тебя хелло ворлд на пару методов или монолит сто в одном)
Ну вот как бы по их словам им не мешает писать модульные монолиты и большие проекты. Мне не особо понятно (чисто потому что не видел), но в целом если работает, не мешает, развивается и все ок в команде - значит это работает, а что еще надо
Kirill
в целом это не очень хорошо работает, имхо, всё же всякого шаред кода дофига
Kirill
ну там сервисы логина, юзер токен, аутх, прочее говно
Kirill
а эта шляпа в целом требует изоляции
Сергей
Ну спорно. Например 2 модуля, юзкейсы - это границы модуля. Один модуль должен вызывать или получить данные из другого. Не всё строится на асинхронщине и ивентах. Вот и вызов юзкейса из другого юзкейса.
Или например был кейс: есть юзкейс создания заказа, а потом пришел заказчик и сказал - хочу атомарную регистрацию при создании заказа незареганным пользователем. Т.е. любая ошибка должна не создавать ни заказ, ни юзера.
По сути был юзкейс CreateOrder а потом создан юзкейс дополнительный, который его вызывал под транзакцией общей - RegisterWithCreateOrder. Почему нет?
Модули в одной транзакции? Ну тут по идее сага какая-то и набор ивентов..
Но если неохота заморачиваться, то можно модули связать интерфейсами.
Павел
в целом это не очень хорошо работает, имхо, всё же всякого шаред кода дофига
Я бы сказал так, я не очень понимаю как это работает, но я бы посмотрел, и в целом как бы более лоялен стал, после того как вполне адекватные люди на опыте сказали "за" такого метода
Павел
Модули в одной транзакции? Ну тут по идее сага какая-то и набор ивентов..
Но если неохота заморачиваться, то можно модули связать интерфейсами.
Ну типа, вместо того чтобы использовать преимущество монолита и БД, мы строим себе сложности в виде саг, ивентов, откатов и прочего. Отличный план.
Не, если большая команда и например проще сделать так, лишь бы сгладить какие то орг моменты - то да. Иначе - я архитектор для беды бизнеса
Сергей
Ну типа, вместо того чтобы использовать преимущество монолита и БД, мы строим себе сложности в виде саг, ивентов, откатов и прочего. Отличный план.
Не, если большая команда и например проще сделать так, лишь бы сгладить какие то орг моменты - то да. Иначе - я архитектор для беды бизнеса
Согласен. Поэтому проще объявить интерфейс создания пользователя и использовать его в модуле с ордером.
Сергей
Можно и хендлер внутри хендлера вызывать , главное держать в голове, что это вынужденная мера, которой не стоит злоупотреблять .
Vlad
Юра
Что логичнее возвращать если не найдена энтити: 404 или 200 и null респонс
Вадим
Что логичнее возвращать если не найдена энтити: 404 или 200 и null респонс
смотря что за запрос
Вадим
и какая энтити не найдена
Вадим
если GET /entity/{id} то 404 конечно
Михаил
Что логичнее возвращать если не найдена энтити: 404 или 200 и null респонс
Смотря что используешь http соединение или голый tcp
Если http то смотря что у тебя: рест или соап
Если голый сокет то вцелом там нет такого понятия как коды, можешь делать как угодно
Юра
если GET /entity/{id} то 404 конечно
Что мне не нравится в этом подходе
1) Не нравится что 404 в случае роут не найден и тот же 404 в случае энтити не найдена
2) На фронте обычно сложнее хендлить такие ответы чем например вернуть 200 и { "result": null }
Юра
Но по феншую да 404 нужно
Михаил
Что мне не нравится в этом подходе
1) Не нравится что 404 в случае роут не найден и тот же 404 в случае энтити не найдена
2) На фронте обычно сложнее хендлить такие ответы чем например вернуть 200 и { "result": null }
1 это простите бред. Сопоставьте кол-во случаев когда вы получаете 404 потому что роут неправильный или 404 потому что не найден ресурс
Михаил
не нравится рест, попробуйте РПЦ
Михаил
ну и то, что если вы обращаетесь в несуществующий ресурс (я имею ввиду когда сервер не знает что такое /a/b/c/123 а не то что /a/b/c/123 не существует в бд) сервер отдаёт 404 - это не совесм правильно
Михаил
я бы отдавал 400 ответ. Если метода нет то мы отдаём 405. Не понятно почему с 404 такая корреляция
Юра
Но вообще да если роута нет то по идее это не 404
Юра
Потому что The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.
Юра
С чего бы ему появится в будущем
Михаил
Что мне не нравится в этом подходе
1) Не нравится что 404 в случае роут не найден и тот же 404 в случае энтити не найдена
2) На фронте обычно сложнее хендлить такие ответы чем например вернуть 200 и { "result": null }
Короче углубись в статус коды и углубись в https://datatracker.ietf.org/doc/html/rfc7483
Посмотри, может ли ваш фронтенд (их http клиент) стандартно обрабатывать rfc7483 контракт и http коды
Если фронтенд скажет что нет, нам удобно сделать 200 и особое тело, то делайте как они скажут
Бекенд должен подстраивать контракт под фронтенд, а не фронтенд должен подстраиваться под то что вы выплёвываете\
Вадим
Что мне не нравится в этом подходе
1) Не нравится что 404 в случае роут не найден и тот же 404 в случае энтити не найдена
2) На фронте обычно сложнее хендлить такие ответы чем например вернуть 200 и { "result": null }
1) а чем конкретно не нравится? в ресте нет разницы роут/ентити и зачем вашему клиенту её знать? Нету и нету
Михаил
1) а чем конкретно не нравится? в ресте нет разницы роут/ентити и зачем вашему клиенту её знать? Нету и нету
потому что обман (грубо, не знаю как мягче сказать).
Это та же история что и если клиент отдаёт ЛИШНИЙ параметр, которого нет в контракте.
Смысл в том что у клиента есть ОЖИДАНИЯ вот я передам age и age должен измениться. Но по ничего не происходит и сервер отвечает 200.
Юра
Мне не нравится что это какой-то особый случай обработки ответа
Юра
У тебя не приходит просто null а кидается исключение типо 404
Юра
Ну ок представь что у тебя функция вместо того чтобы вернуть null если не найден результат кидает исключение
Вадим
потому что обман (грубо, не знаю как мягче сказать).
Это та же история что и если клиент отдаёт ЛИШНИЙ параметр, которого нет в контракте.
Смысл в том что у клиента есть ОЖИДАНИЯ вот я передам age и age должен измениться. Но по ничего не происходит и сервер отвечает 200.
не пойму в чём обман. Ты говоришь дай данные по такому адресу, тебе говорят там данных нет.
Михаил
не пойму в чём обман. Ты говоришь дай данные по такому адресу, тебе говорят там данных нет.
То же самое и с роутом.
Вот он был, а потом пропал. На клиенте 404 обрабатывается нормальное поведение, допустим система уходит в ретрай.
А тут роут пропадает. Если нет особых метрик на сервер вы об этом даже не узнаете.
Михаил
Ну плюс корреляции это не хорошо
Михаил
неверная настройка клиента и не существующий ресурс это разные ошибки
Юра
Вот контроллер, достал из репозитория и вернул результат, ну ок что там нет ничего, результат 200 null. Но приходится проверять наьнул и кидать исключение непонятно почему и как хак ещё и в монолог добавлять что не логировать 404. Не зря как раз этот параметр в монологе как раз и намекает что архитектурно это какой-то костыль
Михаил
Вот я приду в магазин продуктов и буду спрашивать «а у вас автомобиль есть?», они скажут «нет».
Я буду каждый день приходить и спрашивать есть ли, а мне будут отвечать что его нет.
Но если бы они ответили что "мы не продаём машины вообще" это было бы семантически правильно. Ну и я бы перестал долбиться к ним в дверь
Михаил
Вадим
вы вдвоём сговорились но на что-то плохое
Михаил
А ещё мы жёсткие токсики, уууу
Михаил
POZOR
Вадим
Вот контроллер, достал из репозитория и вернул результат, ну ок что там нет ничего, результат 200 null. Но приходится проверять наьнул и кидать исключение непонятно почему и как хак ещё и в монолог добавлять что не логировать 404. Не зря как раз этот параметр в монологе как раз и намекает что архитектурно это какой-то костыль
если вернули 200 то всё что в теле это и есть ваш ресурс
Вадим
это то что вы просили
Вадим
если это не то как надо - вопросы к контроллеру
Вадим
А ещё мы жёсткие токсики, уууу
вам до ларавельских ещё токсить и токсить, просто дУшки по сравнению
Kirill
вам до ларавельских ещё токсить и токсить, просто дУшки по сравнению
ну потому что там хомячки живут в большинстве случаев
Kirill
а их шеймить можно так же, как любой шарпист может шеймить джаваскриптизёров, например
Вадим
ну потому что там хомячки живут в большинстве случаев
да там есть пару персонажей, не хомячки, больше на крыс похожи
Kirill
ну их адель с тёмычем сдерживают)
Kirill
главные токсики чата
Вадим
За Аделем не замечал, а вот Артём это пиздец
Kirill
так это ж самые доблестные защитники чата от толп хомячков
Kirill
которые даже в гугл не могут влезть
Вадим
так это ж самые доблестные защитники чата от толп хомячков
ну так да, в этом смысле они справляются. Хомячки просто в ужасе убегают.
Nikolay
Что не говори, а если писал на симфони долгое время, то на ларавел ни за какие деньги не захочешь
Вадим
За Аделем не замечал, а вот Артём это пиздец
Человек круглые сутки только и делает что токсит. А ещё наверное на работе работает.
Вадим
Что не говори, а если писал на симфони долгое время, то на ларавел ни за какие деньги не захочешь
с фасадика иной раз дёрнуть что-нибудь гденибудь разве не тянет, нет?
Юра
Мы тут недавно обсуждали где флашить доктину. Но по-моему мы упустили момент что можно явно начать транзакцию
Юра
Тогда можно флашить спокойно в разных юзкейсах главное чтобы комит был в одном месте
Юра
Потому что меня все-таки бесит флаш в контроллере, так как например если тебе нужно получить id записи, то ты не можешь это сделать так просто без флаша и какой-то получается кривой сервис который вроде сделал работу но не до конца
Юра
Только не надо сейчас про то что айди должен генерироваться на клиенте, мне это не нужно
Kirill
Kirill
interface Domain\UnitOfWorkInterface
{
/**
* @template T of mixed
* @param callable():T
* @return T
*/
public function persistable(callable $cb): mixed;
}
// Domain\Service
$uow->persistable(function(): mixed {
// всякие вызовы других доменных сервисов
});
Kirill
типа такого
Михаил
В итоге у тебя будет вложенная транзакция так как при флаше доктрина открывает свою
Kirill
ну там не обязательно транзакция
Kirill
зависит от реализации uow, которая через di внедряется
Kirill
да и как бы тут доктрины никакой нет в примере)
Михаил
А ещё доброе утро долгоживущие транзакции когда у тебя долгий http запрос идёт внутри неё
Ну и нагружать бд транзакцией ради «ну так не красиво» кмон.
Kirill
опять же, причём тут вообще транзакции?)
Kirill
это-то да, но в моём случае это просто единица работы, а как оно будет реализовано уже не важно
Kirill
главное что все изменения внутри персистятся/флушатся
Михаил