Максим

Используйте моки и стабы для тестовых двойников. Подсовывайте нужный объект и проверяйте условие.

Не совместный с интерфейсом класс.
Не хватает параметра $userLang = App\Domain\Repository\Language::FR В классе App\Domain\Repository\ChoiceRepositoryInterface

К самому SluggableBehavior это не имеет отношение. Разница очевидна — первый запускается через Web Controller, а второй через очередь из Console Controller. Это значит, что какие-то конфигурации php в консоли и на web отличаются.

SluggableBehavior сильно зависит от расширения PHP php*-intl. Скорее всего, в консоли у вас его нет, поэтому и не работает должным образом. Попробуйте установить его для php который работает с очередями.

Ну а если это не помогает – смотрите логи не только Yii, но и php.

В современном мире действительно стоит разделять backend и frontend. Везде есть свои фреймворки которые стоит использовать для облегчения разработки. Бакенд обычно имеет только api и этого бывает достаточно. А шаблонизатор twig применяют в этом случае для email писем.

Frontend сейчас разнообразен. Это сейчас больше чем CSS+HTML и небольшой функционал на JS. Более того на Frontend сейчас тоже можно делать микросервисы. Одна страница может работать сразу на нескольких JS фреймворках. Например, меню на Vue, а Navbar на ReactJS.

С точки зрения поддержи и развития вы тоже проигрываете. Ведь большой проект требует узких специалистов, в том числе и фронтенд. Если Ваш фронтенд будет на PHP, то на фронтент уже потребуется фул стек разработчик, что дороже и проблематичнее. Значит сложнее масштабирование и развитие. Да и возникают проблемы монорепозитория, куда все изменения с frontend и backend поступают в один репозиторий, без возможности отделения их. Таким образом ко всем разработчикам сразу попадает готовый проект, который легко скопировать и украсть.

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

Достигнут количественный лимит на вызов метода VK API.

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

Лимиты: https://vk.com/dev/data_limits

Можно попробовать какой-то мессенджер с привязкой к телефону, например, Вайбер.

Всё это делать следующим образом… Если есть привязанный к телефону Вайбер, то отправляем код туда, а если нет, то отправляем по смс. Так называемый Chain паттерн.

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

Стоит подумать так ли это дорого. Ведь подтверждение телефона клиента всего один раз.

Фабричный метод — это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов.

В PHP, в отличии от других некоторых языков конструктор один. Из-за чего объект нельзя создать несколькими способами, с другими бизнес правилами. Поэтому принято конструктор делать приватным, а объект создавать через фабричные методы вроде create(), requestJoinByEmail(), joinByNetwork() и другие.

Возьмём всем известных User-ов, которые могут появиться в нашей системе по-разному:

1. Создание пользователя Администратором через метод create().
2. Регистрацией пользователя по Email через метод requestJoinByEmail().
3. Регистрацией пользователя через социальную сеть через метод joinByNetwork().

Таким образом наш объект становится более гибким и содержит в себе разные бизнес требования к состоянию в зависимости от способа его создания.

Чтобы хорошо понять суть рекомендую прочитать полезный ресурс — Refactoring Guru - Фабричный метод.

В любой. Хоть вообще на другой машине, хоть на уровне приложения. Ну обычно делают в web/images, web/uploads, web/file, web/storage/images куда настроите там и будет.

Это формат электронно цифровой подписи прочитать его можно только при наличии второй части ключа.

Это закодированная информация, чаще всего способом base64, а иногда openssl_sign(). То есть это закодированные данные. Прочитать можно при наличии ключа (возможно и ещё других данных) и понимании какой алгоритм был декодирования.

Можно использовать функцию getenv(), если именно так хотите.

Используйте поддержку null значений с помощью allowNull
@Assert\NotBlank(allowNull=true) Разные типы можно валидировать через @Assert\Type(type="integer")

Используйте для декодирования функцию json_decode(), но с вашей строкой что-то явно не так.

1. В симфони роли более продвинутые. Они как бы являются одновременно permissions, что позволяет более гибко работать с ними из коробки. То есть где-то можно использовать просто ROLE_ADMIN, ROLE_USER и этого будет достаточно, но чаще в проектах более сложные права доступа, где можно иметь админа в блоге, админа в магазине и т.д. Вы также можете использовать иерархию ролей, в которой наличие одних ролей автоматически дает вам другие роли.

Определить кто перед вами — ответ к вашему домену, а эти роли показывают какие он права имеет. В данном случае оператора и админа.

2. Как отдавать информацию на фронт? Проверяйте есть ли данная роль в массиве, тут, думаю, всё просто. Опять же повторюсь, что это роли более навороченные, поэтому так. На фронте вообще не всегда нужна конкретная роль. Чаще всего на фронт высылают permissions, по котором проверяют что доступно для отображения, а что нет.

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

Первое с чего нужно начать это проанализировать какое хранилище вам подойдёт, возможно это будет даже не реляционная БД, а какая-то NoSQL. Подробнее о выборе хранилища можно почитать статью на Хабр: https://m.habr.com/ru/post/487498/

Даже если вы не хотите изменять хранилище MySQL на какую-то другую, то вам следует подумать о денормализации данных в отдельные таблицы. Благодаря чему вам не придётся делать сложные JOIN запросы, а все данные будут уже в готовом виде с своих таблицах. Такие данные будут во много раз быстрее выгружаться в отчёты, но и нужно будет следить за актуальностью данных. Собирать эти данные можно по разному: по событиям на этапе создания/изменения/удаления, по крону, по запросу.

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

Для большего ускорения следует отказаться от объектов в пользу массивов. Особенно если запросы идут в базу не на простом SQL, а через какую-то ORM вроде Doctrine. В доктрине происходит маппинг данных на объекты, что очень сильно замедляет работу с данными.

Всё это общие пути оптимизации. Нужно знать больше информации о проекте, о проблеме, чтобы проанализировать и придти к какому-то верному решению.

$array = [22687, 22687, 22688];
$result = array_count_values($array);

Это можно реализовать с помощью UrlManager. Пример можно посмотреть здесь.

1. Отличие VO от Entity это то, то её можно идентифицировать по Id. Так же структура VO не меняется с течением времени. Например, VO Email где бы то не был будет одинаковым и его логика долго не поменяется.

2. Тут зависит от того как вы используете эти Group. Если вам где-то в вашем приложении эти группы нужны, то их лучше создать как отдельную сущность/агрегат. Но можно и сделать их VO в сущности Ticket и хранить только ID Group, либо непосредственно название группы. Все зависит от того как вы работаете с этим в вашем контексте. Например, в контексте справочников Group может быть сущностью и это нормально. А в контексте Ticket можно хранить только ID или само значение.

1. Работу с request используют высокоуровневые вещи вроде контроллеров, поэтому использовать их в своих сервисах не стоит. Ваш сервис это по сути слой связи приложения и вашего кода. Поэтому правильней всего переложить данные из request в какую-то DTO например из патерна CQRS это может быть Command(), Query()

2. Даже когда вам потребуется передавать Request в какие-то свои классы, то лучше для этого использовать PSR интерфейсы. Тогда ваш Request будет фреймворконезависимым. .