Это в обе стороны

Можете посмотреть как в авиабилетах
Покупаю по одной цене, пока вводил данные цена поменялась — мне это к носу суют «тут, брат, цена поменялась, продолжим?»

Но если оформил, через секунду нельзя «докинуть» мол запрос шёл

Ну вот. Значит редкий случай. На самом деле, случай ещё более редкий, чем конкурентный сток на бестселлеры - так что, обман фиг засечешь

читаю Ньюмана monolith to microservices
интересно, что у него в первой главе есть такое
"A distributed monolith may
well meet the definition of a service-oriented architecture, but all too often fails to
deliver on the promises of SOA."
у Уди наоборот микросервисы - это хрень которая шарит данные, поэтому ниоч

Такое ощущение, что Ньюман просто моложе, поэтому ему микросервисы ближе, а Уди постарше, поэтому ещё SOA-хайп застал 🤔

>monolith to microservices
из огня, да в полымя
в любой системе есть слабые связи, есть сильные (функциональные). Монолит - все кодируется сильными, микросервисы - слабыми. Получаем либо хрупкую плохомасштабируемую архитектуру, либо жуткий оверхед по коммуникациям и потерю целостности.
https://www.arbinada.com/ru/node/1651

Ребятки, привет, я создаю dtoшку на сущности, которые прилетают с api, у меня есть controller service и repository, я заворачиваю прилетевший request body в dto на уровне сервиса, это норм ?

Вродь тут можно такое спрашивать

Просто видел, что такое делают на уровне контроллеров, но т.к. там никакой логики, то спускаем на уровень ниже, так ?

На уровень выше, в аргумент-резолверах
Крч в контроллер должны прийти уде готовые дто, зачем эту кухню сугубо техническую внутрь пускать?

На уровень выше контроллера, хм, то есть в резолвере я буду с контекста запроса создавать чистую сущность через дто, а уже в контроллере что то с ней делать, так?

Окес, тогда ещё вопросик, validateService лучше вшивать в (основной)сервис, который принадлежит контролеру или лучше в контроллеры вызвать методы сервисов ?

Ну условно есть usersService и validateService, validate сервис относится к модулю для работы с users

И usersService тож относится к тому же модулю

Блин, надеюсь, что понятно объясняю

список литературы любопытнвй

только ситхи все возводят в абсолют. Можно делать нормально и в ситуации с монолитами и микросервисами (сча нормальный монолит модно величать structured monolith).

Вот тебе кейс когда "микросервисы" хорошая идея - ты работаешь в сфере при которой внесение изменений требует некий жесткий процесс аудита (здравохранение, платежки) - за счет этого можно уменьшить радиус взрыва и изолировать какие-то части друг от друга, при этом эти части могут иметь и разные SLA и разные циклы доставки. "Оверхэды на комуникации" решает соблюдение локальности данных. Ну а тот факт что некоторые фичи становится дорого делать - для этих кейсов это не значительные усложнения с целью увеличить общую скорость доставки.

Что до статьи - не оч понятно к чему притензии к книге. Ньюман довольно много страничек в начале отвел вопросу "может вам не надо микросервисы? вы подумаете, оно не всем надо!"

как это "не надо" ?! А в резюме что писать рядом с "10 лет опыта в пхп"?

а кстати интересно было бы послушать - кто как продал микросервисы бизнесу 🤔

лучше как бизнес пытается микросервисы продать разработчикам)

"у них микросервисы и они деливерят быстро - наверное нам тоже надо!"