Коли Реакт появився, всі плювалися від того що в один файл знову запихнули CSS, HTML та JS. Я теж плювався. Всі роки і практики до цього розповідали як потрібно все розділяти. Але нічого, все чудово працює зараз.

Запити в БД пишуться і виконуються на сервері. Просто тепер не треба створювати напряму окремо сервіс який робитиме запити. По суті до CSS, HTML, JS додали ще і запити в БД, але так додали що цей код завжди виконується і залишається на сервері.

Це погане рішення, яке згодом знову перепишуть.

Тобто на сервері ми тримаємо мільйони pre-rendered _user_view.html, мільярди умовних _transacton_row.html і ще сотні компонентів які можуть виглядати по різному в залежності від того хто їх переглядає та які параметри передані

Звідки взялись мільйони та мільярди строрінок ? Можна конкретний а не сферичний приклад сайту ? Там точно не можна нічого оптимізувати ? Наприклад на доу буде макс 500 найбільш переглядаємих сторінок в данний момент, які поновлюються в кеші.

можна посилання на проект з таким рендерингом

Так, можна посилання,
dou.ua/forums/topic/44975

Але є один проєкт, який я вважаю доволі «дорослим». Це портал Fractal Platform. На сьогодні він моделює функціональність Jira, Slack, має свій блог. У нього інтегровані засоби для деплою та моніторингу програм Fractal Cloud, а також безліч звітів, портал для навчання та проходження іспитів студентами. Усе це навантажує складну систему прав на 12 розділів. Весь UI перекладено 7 мовами. Загальна доменна модель, за оцінками, перевищує 300-350 реляційних таблиць.
Із якою швидкістю має працювати такий застосунок? На це питання складно відповісти, але сьогодні це близько 100 мс на завантаження будь-якої сторінки. А на розігрітому кеші час падає до 12-15 мс.

Скрін

Ну і як виглядає «Реакт майбутнього», а точніше його заміна.
В 450 рядків коду виписаний майже весь фронт-бекенд функціонал на сайт схожий на ютуб
(реєстрація канали підписки лайки коментарі завантаження відео)

fraplat.com/jupiter/UTube

І так, там теж є запити до бази данних прямо з коду, майже як зараз хочуть зробити в Реакт
github.com/...​UTube/UTubeApplication.cs

Але є ньюанс, не лише це має бути зроблено. А коли буде зроблено через 10-15 років все що потрібно, то нарешті застосунки будуть мати не 20 тис рядків коду на подібний сайт, а в ті самі 400 рядків коду. Та латенсі буде не 500 мс, а в районі 100-150 мс навіть без кешування сторінок. А з кешуванням 14 мс як на скріні вище.

Команди розділились на фронт і бек, кожен знає свою область відповідальності. Чому ми тепер йдемо на сервер знову

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

Невже не легше було вирішити ті проблеми які є в SPA, а по суті їх лише 3 — SEO, дублікація логіки валідації даних на фронтенді і бекенді та time to first meaningful paint?

Їх не можна вирішити.

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

Але є ньюанс
1. В статті є контр приклад з Moment.js, де серверу необхідно відправити на клієнт 72 кб. При серверному рендерінгу можна самому все порахувати, та відправити кілька байт як готовий результат.
2. Сервер часто генерує однакові сторінки, та має багато можливостей для кешування та обчислення що називається "не відходячи від каси"©. Перекладати однакову одноманітну роботу на тисячу пристроїв, як мінімум не схвалюють екологи, та виробники батарей для мобільних пристроїв.

Трохи занятно спостерігати, як Реакт наче сліпе котеня, намацує правильний шлях.
Може через 10-15 років буде там де Фрактал вже зараз.
1. Фронт рендерінг
2. Сервер рендерінг
==> Ви знаходитись з Реактом тут <==
3. Сервер та клієнт мають майже однакові БД та спілкуються діфами, замість велосипедування рест апі. Результат: Зменшився обєм коду, зменшився трафік, зросла швидкодія в рази.
4. Оскільки сервер та клієнт повністю знайшли спільну мову, тепер працюють магічні технології, коли база данних відслідковує зміни данних від яких залежать рендерені веб сторінки. Це дає змогу випльовувати вже готові рендерені сторінки за мілісекунди, якщо данні на них не змінились або змінились частково в базі.
5. Енжин навчився генерувати готові веб сторінки використовуючи лише модель данних в базі, що скоростило обєм роботи для круд аплікацій в десятки разів.

В підсумку, що реакт девелопери тільки не видумують, щоб захистити своє право писати в 10-100 разів більше коду, який значно гірше підтримується та повільніше працює. Вони вже інтуітивно розуміють, що там де вони зараз сидять, всидіти довго не зможуть. Але нормально подумати та скласти той весь пазл з фронт-бек-та базою разом не можуть.
Заважає інерційність, "а какжє так"© А вот так.

Скажіть, будь ласка, як ви це бачите?

Що саме бачу? Якщо взяти весь стек вашого коду на Джава
1. На рівні процесору там все кешується в лінійках кешу
2. На рівні дискової системи, все кешується на рівні контроллера.
3. На рівні бази данних там все кешується в своїх локальних кешах
4. І ось прийшов ваш рівень, рівень доменного обєкту і ви такий, нє нє нє ... це не по принципам ДДД бо база данних має бути окремо від домена. Рілі? Яке відношення має одне до іншого. Любий рівень в вашому стеку спроєктований так як спроєктований, та не суперечить доменній архітектурі, тому що купа доменних обєктів що інкапсулюють в собі купу бізнес логіки.

Можете, будь ласка, проілюструвати кодом або псевдокодом:

доменний клас Task з методом UpdateStatus
ентіті TaskEntity
перетворення TaskEntity в доменний клас Task
Можу запропонувати взяти свій репозиторій за основу, але ви, здається, на C# пишете.

Ця задача просто не цікава, вона академічна.
Напишіть в тасці Update Tasks Set Status = Done where ParentId = Id, головне щоб для клієнтського коду нічого не змінилось. Тобто якщо визиває Task.Done(); то виконувалась вся необхідна робота з сабтасками за кулісами.

Давайте, будь ласка, не буде відволікатись на оптимізації, справа не в них.

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

Чи буде він завантажувати при цьому сабтаски (і сабтаски сабтасок)?
Якщо так — це погіршить перформанс для кейсів, коли це непотрібно.
Якщо ні — як тоді виконується UpdateStatus(Done)?

Хто вам заважає не завантажувати весь доменний обєкт. Часткого кешувати, використовувати проксі патерн. Зберігати каунтер в паренті як я вже приводив приклад, зберігати лише айдішники і тільки їх рекурсивно обходити. Це якось суперечить ДДД ? Від того Task перестав бути доменним обєктом що вміє обробляти свої сабтаски мовчки ? Перестав мати бізнес логіку всередині себе? Наче ні.
То що ми зараз обговорюємо?

Повертаємося до початку.

Архітектура і алгоритми це різні речі.

Яка різниця як воно реалізовано всередині. Тут вже що найменьше 3 оптимізації були описані. І ще можна 100500 оптимізацій придумати, щоб воно взагалі за мілісекунди працювало.
Архітектура DDD це про те, що доменний обєкт Task.UpdateStatus(Done) вміє всередині переводити саб таски в Done. Як він це робить — це вже його проблеми. DDD на це питання не має відповідати. DDD лише відповідає на питання, що всі хто працює з Task — не повині писати зайвого коду для обробки Sub Task на своєму рівні, вся ця логіка інкапсульована в доменному обєкті.
І це все.

Але щоб викликати ChildNode.UpdateStatus всередині Domain Object треба, очевидно, його туди якось завантажити, ні?

Очевидно що ні. Щоб обновити статус вам треба знати лише Id сабтаски, та статус в який ви її переводите. Вся інша інфа зайва в памяті в вашому контексті.

А оце мене, власне, і цікавить. Як, наприклад, зробити такий юзкейс — примусове переведення таски (і всього графу її підтасок) в DONE — в стилі DDD?

Навіщо грузити граф?
Класика, коли ви викликаєте Node.UpdateStatus, це також викликає у всіх ChildNode.UpdateStatus всередині Domain Object.
Розумію що ви натякаєте на якісь Bulk Update, але той балк буде ефективнішим коли в вас тих 500 сабтасок. Але судячі з вашої задачі то біт оптимізація, тож в вас є всі шанси лишити красиву DDD ієрархію.

dou.ua/forums/topic/44975

За допомогою GPT я змогла реалізувати цей проект всього за тиждень!

Це звісно добре, що ви витратили тиждень з GPT, але як і в цій темі
dou.ua/forums/topic/45944
те що ви робили тиждень, можна було написати за 15 хвилин і 15 рядків коду.
При умові використання правильних інструментів, звісно.
github.com/...​x2/Sandbox2Application.cs

Проєкт що калькулює ціну пального, може бути корисним для подорожуючих,
створено та задеплоєно поки закіпав чайник.
fraplat.com/jupiter/Sandbox2

За тиждень (5 днів) можна вже написати клон UTube десь на 10-15 скрінів,
там десь 450 рядків коду + дизайн,
fraplat.com/jupiter/UTube

Висновок: GPT + сучасні методи розробки (Python, Java і тп) це дуже не ефективні засоби розробки і мене дуже дивує терпіння та наполегливість людей, котрі то все використовують.
Я дуже лінивий, тому GPT не використовую для програмування, віддаючи перевагу правильним інструментам а не генератору токенів на неефективних мовах програмування.

Я бачу проблему в тому, що, якщо в доменному класі Task є сабтаски — то це вдарить по перфомансу (витягувати всю ієрархію), а якщо нема — то робота с сабтасками буде в сервісному шарі, що ламає всю концепцію. Як вийти з цього протиріччя?

Архітектура і алгоритми це різні речі.
Оптимізацію можна зробити в реактивному стилі, наприклад коли в сабтасці статус Done, вона звертається до свого Parent та робить інкремент ++subTasksDone. Коли subTasksDone == countSubTasks статус парента Done.

На все це ніяк не впливає DDD, доменний обєкт інкапсулює свою логіку роботи, його контракти від внутрішніх оптимізацій не змінюються.

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

Блін, сорян, я забув шо ти в вакуумі і при цьому не думаєш на крок вперед, тому не в курсі що бмпн потрібен для того, щоб його автоматизувати, і тому існують бпмн-двіжки. Це дуже складна думка, да.

Фрактал це і є такий движок. На ньому біля 70% відсотків системи конфігуриться, що називається на льоту.

Погугли нащо це треба, почитай і усвідом, що твоя БД це не вміє принципово. Тому в реальному світі є клас задач, які не вкладаються в raw data + dimensions, що є наріжним каменем твоєї БД.

Що конкретно не може принципово? Ти досі не можеш сформулювати приклад, який принципово недосяжний на «бд з діменшинами».
Є облікові системи на 300+ таблиць які повністью модулюють твої BPMN на Фрактал, розсилки, проходження по статусам, тікети і багато іншого.

ДДД це не про те щоб наляпати DTO класів в найпростішій задачі.
ДДД це про те щоб побудувати N layers, де це справді потрбно.
Тобто обєкт обростає кількома прошарками бізнес логіки.
Доречі, гарний приклад є в ігровій індустрії. В них ігрові персонажі та предмети — це фактично доменні обєкти, з купою своєї внутрішньої логіки. А ті хто цим всім оперує — це сценарій, скрипти, які пишуть гейм дизайнери ігрових рівнів. Це класичний приклад DDD, а не твій копійчаний круд з котом.

Ну тобто приклад який саме тебе цікавить, ти все ще не можеш придумати? Ок.

en.wikipedia.org/...​rocess_Model_and_Notation

І що, навіть найпростіший проєкт що перевіряє світло по таймеру,
та розсилає сповіщення вже формально підпадає під твою діаграму

upload.wikimedia.org/...​ProcessWithNormalFlow.svg

Timer => Check Status Electricity => If Changed, send telegram message to user group => If failed, retry, try resend messages in case of gateway issues

Подробиці з повним розбором коду проєкту
dou.ua/forums/topic/45479

Гарна риса технічного спеціаліста, приводити приклади, що саме маєш на увазі, що саме хочеш запрограмувати. Наприклад Констянтин зробив як гарний спеціаліст, він свій абзац з запитаннями закінчив прикладом, що хоче побачити Ordering в магазині. І я йому прислав приклад коду, що моделює заповнення корзини з товарами, та замовлення.
github.com/...​SupermarketApplication.cs

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

BPMN

Багаторівневе Security, що спадкується, відноситься до нього ? fraplat.com/...​nsionsPages/Security.html

StateMachine для проводу документів по статусам, відноситься до нього?
fraplat.com/...​nsPages/StateMachine.html

Синхронизація, відноситься до нього?
fraplat.com/...​DimensionsPages/Sync.html

Транзакції, відноситься до нього?
fraplat.com/...​onsPages/Transaction.html

Дмитро, я дуже люблю практичні приклади по DDD/CMDD і дуже не люблю демагогію, де купу часу витрачають про наслідування між квадратом та прямокутником, setOwner, activeRecord та інший «rocket science» в якому ти нижче з задоволенням приймаєш участь.
Мене цікавлять як замість 50 тис рядків boiler plate, писати 500-1000 рядків і отримувати більш гнучкі, більш конфігуровані та швидкі аплікації. Якщо в людини є прогресивний погляд, та вона відкрита до чогось нового, що дає дійсно класні переваги — я завжди велкам.
Є код, є приклади, є задеплоєні проєкти. Як ні, то ні, не всім бути реформаторами. Деякі відчайдушно чіпляються за старі технології, навіть якщо вони не дають ніяких переваг.

Бо яка така властивість «пагінація» (чи «сортування») може бути у юзера?

Насправді, в фундаменті є потужна математична модель. Люба колекція з json документами, це фактично колекція ієрархічних обєктів. В ієрархії можуть бути інші вкладені обєкти. А над цими списками може бути застосована така властивість як Pagination. Фактично цей dimension каже, що всі клієнти будуть чититати не всі обєкти скопом, а пейджами.

Приклад, фотоальбом. Є документи (зараз один але може бути більше)
github.com/...​hotoAlbum/Photos/Document

{'Photos':['Photo1','Photo2','Photo3']}

А є pagination dimension, який каже що не всі обєкти з масиву Photos ми читаємо, а читаємо порціями по два елемента
github.com/...​/Document/0000000000.json

{
  "Photos": {
    "Page": {
      "Attrs": 2,
      "IsAlign": false
    }
  }
}

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

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

Це дуже просто, наприклад в нас є документ в колекції Backets

{
  "Client": "Bob"
  "Orders": []
}

В нас є шаблон замовлення, в колеції NewOrder

{
  "Name": "Apple M1",
  "Category": "Notebooks",
  "Price": 1000,
  "Quantity": 1
}

Далі ми пишемо в код

CreateNewDocForArray("NewOrder", "Backets", "{'Orders':[$]}").OpenForm();

Відкривається веб форма, після її заповнення, замовлення додається в Backet (корзину)

{
  "Client": "Bob"
  "Orders": [{
  "Name": "Apple M1",
  "Category": "Notebooks",
  "Price": 1000,
  "Quantity": 1
}]
}

Dimensions на справді дуже багато, більше 50
fraplat.com/...​nsionsPages/Document.html

Всі вони є фактично частиною DDD, та допомогають побудувати Rich обєкт.
Коли ви побудували його (фактично наконфігуривши джисони) вам лишається лише описати загальні сценарії роботи з цими доменними обєктами. Підход дуже простий і гнучкий.