Василий Банников

С точки зрения архитектуры это нормально.
Но чтобы ответить, правильно ли это вообще - нужно больше данных.

Никакая. "ОС" в opencomputers - это просто скрипт на lua, который имитирует своим поведением работу операционной системы.

В реальных проектах используют разные варианты исходя из личного опыта и настроения каждого члена команды на момент старта проекта.

Может быть и супер сложный clean architecture + DDD + CQRS.
Может быть Vertical Slice.
А может быть и предельно простая архитектура даже без разделения на проекты (крайне недооценённый вариант на самом деле)

У всего есть свои плюсы и минусы.

Чтобы UI был, нужно чтобы плагины либо сами html генерировали, либо чтобы они генерировали какое-то абстрактное представление, которое уже ты как-то переведёшь в html.

В принципе тут даже не обязательно razor использовать.

Как подгружать плагины, я думаю, вы уже знаете.

есть ли средства более быстрые, чем PHP-фреймворки?

Да, готовая CRM или какое-нибудь lowcode-решение, где половина крупных модулей уже написана.

откуда лучше брать сервера?

Поднять свои.

Получается должен быть какой-то Бекенд, на чём его писать?

На том, на чём умеешь.

Какие нагрузки он может выдерживать, тут ещё получается надо бы, чтобы эта система сама себя масштабировала, сигнализировала, если сервера перегружены, чтобы надо было ещё подключить.

Ну тебе с твоего бэкенда надо будет собирать метрики по задержкам, нагрузке на CPU, и RAM.
Решений этой задачи много. Гугли "сбор метрик с бэкенда".

Автоматическое масштабирование - тема отдельная и достаточно сложная.

Может быть есть уже какой-то готовый сервис который предлагает готовое решение

Да, есть. Многие vpn-провайдеры имеют так называемую услугу "white label" - они сами делают клиент с твоим логотипом, названием, и может даже дизайном, но за инфраструктуру отвечать будут уже они.

Быстро и по сути ноль головной боли, если у тебя задача просто сделать свой vpn-сервис

Лично я вижу только одну причину иметь самостоятельный лаунчер - ты хочешь распространятся независимо от сервисов онлайн-дистрибуции типа стима, но при этом ты хочешь, чтобы игрок мог легко получать все обновления.

Выбирай от того, как предполагается использовать.
Если ты разрабатываешь и клиент и сервер, и при этом клиент нормально умеет в grpc (не браузер) - бери grpc.
Если ты разрабатываешь только сервер, а клиенты разные с разными потребностями - тогда graphql.
Ну и никто не запрещает комбинировать - можешь сделать сервер с grpc, а клиентский api предоставлять с graphql

Критерии оценки зависят от того, кто и зачем оценивает.
Хорошесть опять же зависит от того кто оценивает.

Для владельца, сайт может быть хорошим, если приносит большой доход за счёт рекламы и слежки за пользователями.
Для конечного же пользователя этот же сайт может быть плохим из-за рекламы, слежки, тормозов, и устаревшего дизайна.
QA скажет, что сайт хороший, тк полностью соответствует всем функциональным и нефункциональным требованиям, и решает поставленные задачи.

Так что определяй сам для себа важные моменты и формируй от них критерии оценки.

Однако возник вопрос относительно красного слоя - use cases

Use-cases это то, как пользователь взаимодействует с вашим приложением. (написано Application Business Rules)

Entities - данные и правила работы с ними (написано Entreprise Business Rules)

Я правильно понимаю что в классическом MVC красный и зеленый слои не разделяются, т.к. логика пишется в контроллерах (или моделях, неважно). Или же зеленый слой представляет из себя только роуты, а красный - контроллеры, модели?

В контроллерах пишется только логика, которая склеивает модель и вьюшку. В идеальном случае контроллеры должны быть однострочными

Также не особо понял почему Робер выделяет в самый верхний слой Базу данных.

В самом ядре находятся сущности, которые не обязаны 1-в-1 преобразовываться в модели БД.
Сам слой с базой данных - это External Interfaces, как и фреймворк.

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

В том и смысл Clean Architecture, что никто от БД не зависит.
Должна быть какая-нибудь абстракция, которая позволяет получать данные, а в отдельном модуле уже будет реализация поверх БД.
Об этом в той самой книжке тоже говорится с соответствующими картинками.

В AWS есть Fargate - все долгие операции можно скидывать в него.

Напишу псевдокодом:

пусть значение = получить_значение_из_поля();
пусть результат = запросить(значение);

Вообще, порождать новые потоки на каждый запрос - это не очень. Лучше использовать асинхронщину. Хз что там в жаве для этого есть, если честно.
Для парсинга ответа есть GSON.
Если бы вы использовали kotlin, то я бы посоветовал использовать ktor или http4k