Архитектура как мышление⁠⁠

Как я перестал писать код и начал проектировать смысл

Когда ты пишешь код достаточно долго, в какой-то момент перестаёшь интересоваться фреймворками, и начинаешь интересоваться — почему ты пишешь именно так.

Я программист. Пишу на PHP. Много лет. Экспериментирую.
И как у всех — были MVC, DI, EventDispatcher, DDD, REST, GraphQL, всё.
Но однажды я понял: настоящая сила не в паттернах.
А в переосмыслении самого подхода к архитектуре.

Декларация → Компиляция → Исполнение

Каждый модуль — это фрактал:
Domain, Application, Infrastructure, ModuleAssembly.

Модуль не "работает". Он просто заявляет, что умеет:

Архитектура как мышление PHP, Архитектура, Код, Парадигма, Программирование, Мышление, Длиннопост

Декларация модуля

Когда система говорит:

Ожидание интерфейса

Контейнер спрашивает у мира: «Кто умеет это?»
И мир отвечает:

Конфигурация модуля

Контроллер как декларация

Вот пример реального контроллера. Он ничего не валидирует, не авторизует, не логгирует вручную. Он просто говорит, что нужно сделать:

Пример контроллера

Что на самом деле происходит:

— Guard проверяет доступ по IP-группе
— Configurator подключает зависимости
— Route компилируется на старте
— Mapper обрабатывает исключения
— GlobalEvent фиксирует событие

Ты больше не пишешь "что делать".
Ты декларируешь смысл.
А архитектура сама решает, как это выполнить.

Это не просто DI.

Это — реакция. Это смысл. Это мышление.

Будет доклад. Может — книга. Может — просто PDF для своих.
Но если ты хочешь быть среди тех, кто не просто пишет код, а мысленно строит системы — оставайся на связи.

Архитектура как мышление. Это уже началось...

ddrv

Ну вот последний скрин:

$this->service->createForm($token);

$this->response = $this->service->getResponse();

Хотите сказать, что результат $this->service->getResponse() вообще не зависит ни от вызова $this->service->createForm($token), ни от значения $token?

раскрыть ветку (1)

Зависит, но это не значит, что я должен в сервисе хранить состояние

показать ответы

WebFormService выглядит отстойно. Если сервис передаётся в контроллер, а не создаётся в нём, то он должен быть без состояния. Но у Вас он вот точно с состоянием (сначала вызывается метод createForm($token), а потом getResponse()). И это состояние может сыграть злую шутку.

__construct(private readonly ScopeVariables $scope). В сервисах нет состояния. Практически все сервисы readonly

DELETED

Звучит так что Вы пробовали все кроме AOP )))

Ага, я прям целенаправленно не изучал. Говорят, там магии много (неявного выполнения). А хочется, чтобы все вышли из сумрака :)