Мой сарказм про психологов был скорее в том, что у людей всегда есть диванный совет, как все исправить, но по-факту попасть в хорошую тиму действительно сложно)

зато можно сделать кодфлудилку флудилкой в одно ))

не блейми меня

Simple Made Easy

Для меня простота системы является одним из ключевых признаков качества и хорошей архитектуры. Систему, которую легче понять, проще ментальная модель, прозрачней решения (принятые и которые нужно принимать), почти всегда легче развивать. В то же время, создать простую и стройную систему всегда сложнее, а сложную - проще :).  Простые системы часто имеют меньшую вариативность состояний и более предсказуемы. Это касается и тулинга и бизнес-логики. Также это перекликается с идеей, что если ты не знаешь в какой слой разместить кусок кода, то скорее всего у тебя проблемы с архитектурой (ее нет, ее сложно осознать и тд).  Но иногда я встречал решения, которые оптимизированы под легкость использования. Можно ли сказать, что легкость использования и простота системы это одно и то же? По ощущениям эти понятия перекликаются, но часто уклон в легкость использования делается, когда системы слишком сложная. А сложность часто продиктована чрезмерной связаностью частей системы, в результате получается комбинаторный эффект от взаимодействий/состояний. Почему я про это все говорю? Мне просто попался хороший доклад на эту тему :). Докладов, которые не про пересказывание документации, а про осмысление подходов не так много. Сам доклад 2012 года, но актуальности он не потерял. Рекомендую.

ССЫЛКА НА ДОКЛАД - https://www.youtube.com/watch?v=oytL881p-nQ

Ещё Simplicity Matters

По описанию чувствуются истоки Чистой Архитектуры от дяди Боба

Кмк есть проблема что абстракции текут

То есть часто используя сложные(внутри) инструменты, призванные для того чтобы облегчать жизнь, нужно понимать как они под капотом работают

Очень часто

Если задумываться об этом нужно при использовании регулярно, а не единожды осваивая его, то он уже не простой, а сложный и для разработчика и для пользователя

Как Symfony Messenger

Как Доктрина

про мессенджер расскажешь?

Мессенджер сойдёт если задачи решает

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

Или там, что неймспейс и имена DTO-х менять не нужно

Всякие эти stamp`ы и envelop`ы

они в базе как-то фигурируют или как?

Имя класса зашито в мессаджи