що десь за 7-8 років кар’єри вони все одно будуть на плюс-мінус тому самому фінансовому рівні

Це нісенітниця. Зміною роботи можна (було в жирні роки) легко піднімать собі зп на +1-2к а то й більше. Середньостатистична галєра ніколи не піде на такий рейз через жлобізм. Їм легше втратити тебе і найняти заміну.

свіч — чудова і архікорисна конструкція, викидувати її з мови це дурість.

Є тільки 2 правила — пам’ятати про break і завжди реалізовувати default.

Це ти собі якусь персональну термінологію видумав

Ну або ти на все дивишся з точки зору database only. Якщо забути про те, що навколо бд є інший світ, і жити виключно всередині бд, то так, тоді distributed буде так само про скейл>1 тільки про інстанси бд.

Я ж не живу у бд, тому цей термін має інше значення.

Ти взагалі не зрозумів, про що я написав.

Мова йде про скейл>1 клієнта.

І тобі привіт )

(і в тебе, здається, теж) — так, домен прибитий до persistance

Звичайно прибитий )

Лейзі-вс-ігер лоадінг взагалі бездонна тема.

В окремих випадках я взагалі розв’язую один віж одного об’єкти і підвантажую їх зв’язки окреми селектами типу ListChild findAllWhereParentIn(ListParent)
а потім уже в пам’яті дроблю загальних ліст чайлдів на мапу

А як select ... for update буде афектити якісь «звичайні селекти» щоб тормозити аналітичні вигрузки?

Отут ступаю на тонкий лід, бо сам я не дба, в кишках сучасниз бд не розбираюсь, і лише оперую чужим досвідом у цій сфері.

Я консультутвався з кількома дба в світерах з приводу ...for update. Всі опитані незалежно один від одного підтвердили що в великих кількостях при великій інтенсивності блокувань ...for update може викликати блокування окремих пейджів бд і викликати очікування при селектах. Всі також підтвердили що при високоінтенсивному використанні блокувань їх краще взагалі виносити за межі БД. Один додав що в інфраструктурі SAP є окремий сервіс для блокувань спеціально зроблений з метою рознесення БД і ресурсів що блокуються.
Якось так.

Виходячи з ідеології рознесення відповідальності для себе я вирішив що кращим сценарієм є розподілені локи винесені поза межі БД, і з тих пір успішно з ними працюю.

До чого тут взагалі distributed?

До того що абсолютна більшість софту крутиться зі скейл>1 і по факту стає розподіленою системою.

distributed — це коли мова йде про забеспечення транзакційності на рівні одночасно кількох БД.

Ніт. Це коли є конкурентна модифікація одних і тих же даних навіть в 1 БД, яка може прийти з фізично різних машин.

передбачаю що різні сторонні рішення так чи інакше працюють через використання нативних засобів БД

Невірне передбачення )

а цілістність і консистентність даних — а що воно взагалі таке?

Ну таке, я не сперечаюсь що прошарок людей які не задумуються над цим є. Але це до першого адського дебага «а чому так сталось».

На 10.
7ка хапала вірусню аж бігом без антивіруса.

Колись це був Аваст, хороший був антивірус.
Зараз це дефендер, бо справляєцця «з коробки».
Есет завжди був лайном.

А.

А потім будете питати а чого це так БД повільно працює?! А кто ето сделаль? А чого в аналітични вигрузках або немає даних або вони робляться по 6 годин.
Загалом так робить конєшно можна, але це або хеловорлд-левел, або треба мати окремі таблиці для блокувань

Б.

Подорожнік, підпертий костильом, з пластирем на якому написали «не ламайсь»

Доросле рішення — distributed fenced lock.

Нажаль, мій досвід з «солюшн архітекторами» з єпама був вкрай негативний.
«Аріхтектор» приходив раз на кілька тижнів, заливав пафосом і ЧСВ весь мітинг, демонстрував повне нерозуміння проблематики проекту і загальну технічну безграмотність, але вказівки роздавав.

пукнути в муку)

Він хоч пукнув, хоч ні, але ти обтрусись

Він правий. Чатгпт просто генерує текст, який є правдоподібним через власне нейромережу. Він не здатен валідувати власні відповіді.

От тобі непогана ввідна стаття з конкретикою www.baeldung.com/...​l-architecture-ddd-spring.

Повна шиза:

We won’t register it as a Spring bean because, from a domain perspective, this is in the inside part, and Spring configuration is on the outside. We’ll manually wire it with Spring in the infrastructure layer a bit later.

Це просто квітуча шизофазія, вирішення неіснуючих проблем.
Двукратна імплементація репозиторія боже яка діч.
І сам дизайн доменних об’єктів до речі теж гівняний.

Все в світі спочатку стає джаваскріптом, який еволюціонуючи, перетворються на джаву )
Так точніше )

адже кожний окремий запит може вимагати майже рандомну комбінацію атрібутів

І це також одна із найважливіших і в той же час найгірших особливостей графкл

У них всіх є media.

Вичерпна характеристика структури і сутності даних (ніт) :)

У них всіх є media. Для REST це /users/{useId}/media, /products/{productId}/media, /messages/{messageId}/media.

Для GraphQL це буде поле media в моделях user, product, message

Ну це якщо руки криві і голови на плечах немає, чистота тут ні до чого.
І по всіх твоїх питаннях, а саме:

Робити кучу реквестів?

Добавляти поле в модель?

якщо десь буде список де media не потрібен?

Треба виходити з природи сутності медіа, яку ти ввів, але не описав. І з природи взаємодії користувача із цими «медіа», не знаючи юзкейсів і сценаріїв, що воно то «медіа» значе, я не можу робити будь-яких висновків про те, як будуть виглядати операції з ними.

В GraphQL того факту що модель має поле media достаньо.

Ну да, да, це якраз яскрава ілюстрація про той ущєрбний підхід, про який я говорив:

я ніхочу в дизайн взаємодії бека і фронта я хочу плюшевого тіраназавра все разом одним запитом тутже сразу дайтє мнє

Тобто, ти не хочеш думати про взаємодію сутностей і напрацьовувати не-конфліктну взаємовигідну схему обміну даних фронта і бека, поділену на юзкейси і сценарії, тобі глибоко пофіг що там на бекенді, тобі треба всього зразу, щастя задарма для всіх і щоб одним запитом.

Коли піде реквест, то викачається список юзерів, з них візьмиться mediaId і одиним запросом із списком media ids сходить в базу. Це все не покидаючи бека.

Ти оце так описав це мені нагадало жартівливий відосик з діпфейком де безугла вчить Залужного як воювати «ну там самольотікі літять бах бах піхоти біжуть кулеметами тра-та-та отак треба робити контрнаступ».
На практиці все шушуть трошки складніше получається. Точніше не получається, а получаються милиці, як вже тут писали «додав поле в респонс і чекаєш 30 секунд». Бо структура запиту і резолвери які розпідарашені по кускам бекенду не адаптовані до такої псевдо-гнучкості.

І це ще я не розписував, що вся проблематика про юзерів, продкути, месаджі і меді трохи висмоктана з пальця і елементерно вирішується рестом, але при умові, що сценарії використання даних продумані.

Чи можете більше розкрити свою думку?

Можу.

Моя думка не базується на метриках, чи дослідженнях, а є виключно суб«єктивною і заснованою на моїх роздумах щодо концепції графкл і трошки на практиці.

Отже, чому графкл це всрата шляпа.

По-перше, тому що для неї придумали жсоно-подібний-не-жсон. Це убого. Документи графкл зі складністю вищою за хеловорлд важкочитабельні

По-друге, тому що сама концепція цієї технології починаючи з самої ідеї ущєрбна* і однобока — давайте ми зробим протокол який буде розрахований виключно на комфорт і потреби фронта бо на бек розробників нам пахую, а як він буде працювати на бекенді нас не їбе вапще, їбіться самі якось самі придумайте.

По-третє, ущєрбність самої думки про відсутність схеми і «я получаю тіко те що я хочу». Пахне якимось інфантилізмом в стилі узьких наротних вологих казок про іванушку-дурачка якому в житті все щука зробила. Графкл — це аналог такої щуки тільки в світі протколів «я фронтенд дівєлопер, я ніхочу в дизайн взаємодії бека і фронта я хочу плюшевого тіраназавра все разом одним запитом тутже сразу дайтє мнє»

Концепція технології зводиться до того, щоб максимально спростити роботу фронтенда ціною пахую ваще різкого і неконтрольованого ускладнення логіки роботи бекенда та і ще раз пахую можливого викривлення схем зберігання даних для адаптації під ускладнену логіку обробки запиту.

На моєму досвіді з GraphQL все було дуже добре

Це може бути з двох причин, або А) якщо ви чисто мобайл-фронтенд, то у вас однобокий досвід, отриманий з тієї сторони, до якої графкл повернутий рожевим боком з понями і радугою. А на бекенді досвід часто зводиться до такого, як вказали нижче:

А часто буває так, що додаєш одне додаткове поле до респонзу і відповідь приходить не за кілька секунд, а за 30-60 секунд.

і така ситуація виникає не тому що у бекендерів руки криві, а через концепцію технології, яка змушує бекенд працювати за контрінтуітивними сценаріями.
...або Б) у вас адіщенськи примітивна схема даних

* русизм але я не можу підібрати українського слова з таким же спектром емоцій

GrahpQL це мабуть одна з найгірших хєровин яку можна принести в проект.

А рубі без рельс існує? 0.о