Евгений Ромашкан

1. Swoole/Amp/Wokerman/ReactPHP если на PHP. В целом не очень популярные инструменты, но справедливости ради замечу что на Swoole работают весьма крупные приложения в Китае, тот же baidy, tencent, игрухи всякие и т.п.

2. Centrifugo/Roadrunner как простой гейтвей. Не так давно вышел, более известен, вроде никто не жалуется(я не использовал).

3. Самописный гейтвей для вашей аппки на Node.js/Go etc. Надежный вариант для которого всегда можно найти разработчиков(в отличии от первых двух).

p.s. Варианты на PHP годятся лишь чтобы работать с websocket тем-же. Чтобы не возникало желания таким образом "ускорить" своё приложение - вот вам ещё немного разбора полётов от автора php-service-bus со сноской почему прикручивать асинхронщину к существующим мейнстрим-php-фреймворкам так себе затея

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

Конечно пересекаются. Потому что это не разные модули.
Система делится на модули исходя из зависимостей, а не по тому как все на UI выглядит.

Может достаточно по директориям раскидать контроллеры и вьюхи? Моделей мало. С роутами наверное можно будет по-ходу дела, что-то придумать.

Для чего "достаточно"? Чего конкретно этими действиями хотите достичь?

как правильно реализовать авторизацию с токенами, сделать корзину в онлайн магазине и.т.д,

Есть бесконечное число вариантов сделать корзину в онлайн магазине, и бесконечное число переменных влияющих на принятое решение.
Вы знаете что такое комбинаторный взрыв? Это именно то что произойдёт если вы будете пытаться запомнить все реализации любых задач, не говоря уже о том что любая новая задача остаётся по прежнему уникальной(в какой-либо степени), и просто копирование решения из похожей задачей почти никогда проблемы не решит, а в связи с упомянутой выше проблемой в виде множества обстоятельств влияющих на набор выбранных решений, слепое их копирование скорее сильно навредит развитию проекта, чем поможет в сколь-либо обозримом будущем.

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

P.s. кстати, последнее что я смотрел про проектированию корзины - вот. Полезный ролик чтобы взглянуть на вещи по новому, но не для того чтобы копировать решение. естественно.

Стоит задача описать 3 абстрактный класс который наследует в себе 2 класса

Задача изначально поставлена некорректно. Само по себе наследование двух абстрактных классов никакой практической пользы не принесёт, и не даёт никакой уникальной функциональности которую невозможно реализовать через наследование.

Если вам кто-то даёт такие задачки под видом "задачек по ООП" - лесом его надо слать. Все эти наследования Customer от User, User от Human на практике в 99% случаев не нужны, т.к если условно модуль хочет себе Покупателя(Customer), ему нет разницы, Человек(Human) там, или робот и т.д, а любое наследование это жесткие иерархии классов в коде, лишняя связность(чит. Coupling) и лишние зависимости между компонентами, что делает код более сложным для понимания и изменения.

Зачем в данном случае, наземно-воздушную MaskCar наследовать от StandartCar и StandartPlane? Всегда ли она будет вести себя так же как её родители, не будет ли нарушений принципа подстановки(см. Liscov Substitution Principle)?
Если MaskCar планируется изменять независимо от родителей, даже если по каким-то причинам на текущий момент она реализует те же методы, нет никаких проблем определить те же методы в новом классе заново, и при необходимости реализовывать интерфейсы Car и Plane(ICar и IPlane в вашем случае).
Если нужно поведение родителей, в большинстве случаев наследование можно без проблем заменить композицией, если речь идёт о C#, можно также очень удобно решать такие проблемы через делегирование(https://metanit.com/sharp/tutorial/3.13.php)

Объектная гимнастика

Мало что можно сказать по паре десятков строчек кода, даже без гитхаба с проектом. Пара примечаний:

1. Очень смущает парметр $args в методе execute(). Массив, типы и элементы внутри которого не определены, потенциальный источник многих проблем.
2. Зачем прокидывать DI в контроллер?

И совет - попробуйте psalm. Ставится и запускается на дефолтных настройках в два клика, позволит избегать огромного количества проблем с типами, и понимать где проблемы, никакие обращения к необъявленным явно элементам в массиве там уже не прокатят

Domain Events

Можно, формально все будет работать точно также (ну только в один js файл все не скомпилируется), но вы потеряете все преимущества использования сборщиков фронтенда и пакетного менеджера

Тык
P.s. Do not parse HTML with regexp

class App {
    public function getLocale();
}

function app {
    return new App(); // в вашем примере тут синглтон
}

Воспользуйтесь переходом к определению в вашей IDE, или поставьте PhpStorm если в вашей среде разработки нет такой возможности, чтобы отследить где объявляется эта функция

p.s. но вообще, очень так себе подход, тут и статика, и глобальное состояние. Глобальный App в php только в Yii фреймворке я видел, да и те одумались и вроде выпилят его в 3 версии(если она будет, конечно)