Анемичная модель предметной области и логика в сервисах

Без сравнение показать "почему логика в сервисах является более правильным подходом", мне кажется, невозможно. У вас в голове есть некоторая реализация Rich Domain Model к которой вы апеллируете, но у тех кто читает статью, этой реализации нет, поэтому статья кажется неполной

Анемичная модель предметной области и логика в сервисах

чтобы можно было сравнить реализации и оценить возможные проблемы

Было бы круто увидеть реализацию с Rich Domain Model

Использование Symfony / PHP

К примеру вот: https://github.com/symfony/symfony/discussions/46789

Symfony Json RPC API Bundle — простое API со всем необходимым

По поводу MethodSpecCollection и инициализации при каждом запросе

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

$collection = new MethodSpecCollection();
$collection->addMethodSpec('foo', $container->get(FooMethod::class));
$collection->addMethodSpec('bar', $container->get(BarMethod::class));
// И так 100500 раз

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

В случае в локатором будет что-то вроде:

$serviceLocator = new ServiceLocator();
$serviceLocator->addMethodSpec('foo', fn () => $container->get(FooMethod::class));
$serviceLocator->addMethodSpec('bar', fn () => $container->get(BarMethod::class));
// И так 100500 раз

т.о. они будут отрезолвлены в методе get

Symfony Json RPC API Bundle — простое API со всем необходимым

И в файлике config/services.yaml в секцию services добавить раздел с той папкой, которая предполагается для реализации всех ваших дальнейших методов API.

Лишний шаг, т.к. у вас все равно на эти методы навешиваются аттрибуты. В OVJsonRPCAPIBundle::build можно сделать что-то вроде

$container->registerAttributeForAutoconfiguration(
    JsonRPCAPI::class,
    function (ChildDefinition $definition, JsonRPCAPI $attribute) {
        $tagAttributes = get_object_vars($attribute);
        $definition->addTag('ov.rpc.method', $tagAttributes);
    }
);

MethodSpecCollection в идеале заменить на ServiceLocator, чтобы не инициализировать все методы при каждом запросе

P.S. Почему выбрали gitflic в качестве хранилища? У меня он composer.json как-то странно рендерит.

Yii Validator — простой и мощный

3. Можно обойтись без бандлов: https://gist.github.com/BoShurik/009cdeef1fb7a43fc1856feaaf317062

Игры созданные в одиночку и Заработавшие Миллионы

Рекомендую Return of the Obra Din от создателя Papers, Please. Судя по всему опять создана в одиночку

Прикручиваем шаблонизатор Blitz к Laravel

Я бы предпочел чтобы шаблонизатор мне сообщал об необъявленной пременной, в противном случае опечатаетесь в каком-нибудь флаге, и он у вас навсегда false, и сообщит вам об этом только клиент

Почему PHP — это моя ошибка

Да, так нельзя, но нас спасают статические анализаторы:

/**
 * @template T
 */
class Sample {
    /**
     * @param T $someData
     */
    public function __construct(public $someData)
    {
    }
}

/**
 * @param Sample<string>[] $input
 */
function someFun(array $input): void
{
    print_r($input);
}

someFun([new Sample('string')]);
someFun([new Sample(10)]);

https://psalm.dev/r/658910a73a

Использование ООП подхода для рассылки писем через Unione (php, Yii2)

Формирование тела запроса мы от туда убрали, т.к. тело запроса зависит от отправителя. Остается подготовка данных. В чем она заключается? Срендерить шаблон и передать туда переменные? Ну я бы это тоже через отдельный сервис сделал, чтобы не зависеть от шаблонизатора.

Мне кажется это обычный дата-класс (его даже абстрактным делать не надо, чтобы можно было отправлять простые письма)

Использование ООП подхода для рассылки писем через Unione (php, Yii2)

потому что суть статьи была не в нём, а в классе Message

А что в нем? Если убрать отправку письма в отдельный сервис, то что в нем остается?

Почему PHP — это моя ошибка

Позволяет

function doSomethingWithIntegers(int ...$integers): void
{
    var_dump($integers);
}

doSomethingWithIntegers(1, 2, 3);
doSomethingWithIntegers(...[4, 5, 6]);

Преобразование формата ошибок с помощью встроенных событий Symfony

Как бонус:

GET http://127.0.0.1:8880/
Accept: application/xml

###

#<?xml version="1.0"?>
#<response>
#    <type>https://tools.ietf.org/html/rfc2616#section-10</type>
#    <title>An error occurred</title>
#    <status>500</status>
#    <detail>Internal Server Error</detail>
#</response>

Использование ООП подхода для рассылки писем через Unione (php, Yii2)

Ссылка ведет на статью про сервис локатор (который собственно и создан для того чтобы find the service) + он таки ищет этот сервис с помощью Yii::$container. Это ли не оно?

Ну и вы просто вдумайтесь, какого будет потом дебажить такой код. Ни намека на то, чем является $this->mailer

Преобразование формата ошибок с помощью встроенных событий Symfony

Если в проекте подключен symfony/serializer, то будет работать из коробки

composer create-project symfony/skeleton symfony-accept-format
cd symfony-accept-format
composer req serializer 

GET http://127.0.0.1:8880/
Accept: application/json

#{
#    "type": "https:\/\/tools.ietf.org\/html\/rfc2616#section-10",
#    "title": "An error occurred",
#    "status": 500,
#    "detail": "Internal Server Error"
#}

###

GET http://127.0.0.1:8880/
Accept: text/html

###

#<body>
#<div class="container">
#    <h1>Oops! An Error Occurred</h1>
#    <h2>The server returned a "500 Internal Server Error".</h2>
#
#    <p>
#        Something is broken. Please let us know what you were doing when this error occurred.
#        We will fix it as soon as possible. Sorry for any inconvenience caused.
#    </p>
#</div>
#</body>
#</html>

Использование ООП подхода для рассылки писем через Unione (php, Yii2)

Вот на php: symfony/mailer

Использование ООП подхода для рассылки писем через Unione (php, Yii2)

Там дальше по тексту отдельно упоминается service locator

Because the client does not build or find the service itself, it typically only needs to declare the interfaces of the services it uses, rather than their concrete implementations.

Создание сервера для онлайн ММО игр на PHP ч. 4 — Redis

Мне кажется, вы отбрасываете саму игровую логику, которая и будет бутылочным горлышком. Я бы сначала сделал игру, со всеми фичами, которые хочу видеть. И уже на ней бы экспериментировал с технологиями

Создание сервера для онлайн ММО игр на PHP ч. 4 — Redis

Ну, кстати, из этого FAQ видно, что для вашей целевой аудитории не особо важно количество игроков онлайн

Most Photon multiplayer games have 2-16 players
There are Photon games live with 32 or even 64 players

Откуда желание повысить онлайн? Это какой-то запрос от реальных разработчиков игр? Или просто цель с потолка?

Создание сервера для онлайн ММО игр на PHP ч. 4 — Redis

При этом, надо сказать, что лично у меня сложилось ощущение, что BrowserQuest сильно выигрывает у вашего Игоря по отзывчивости (и там и там было по одному игроку).

Вам нужно сделать что-то аналогичное, потому что техническая демка - это не то, чем нужно заманивать, а вот на BrowserQuest я залип надолго (и соответственно тыкался в ней минут 30, в отличие от вашей игры, где меня хватило на пару минут)