Максим

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

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

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

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

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

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

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

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

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

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

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

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

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

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

public function show(string $slug, RegionFetcher $fetcher): Response
    {
        $region = $fetcher->findOneBy(["name.slug" => $slug]);
        return $this->render('app/admin/location/regions/show.html.twig', ['region' => $region]);
    }

Файл .env. Подробно в документации

Если бы вы прочитали документацию и ещё, то Вы бы не задавали подобного вопроса

Вы определитесь: Вам нужно поучиться или подобрать стек под проект?

Если поучится, то тут вопроса не стоит. Просто скачивайте Symfony и начинайте. Возможно, Вы потратите больше времени и сил, чем с Laravel. Но зато попробуете для себя новый, перспективный фреймворк. Symfony не сложный. Он просто имеет другие подходы в разработке и требует от разработчика более строгого подхода в написании кода.

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

Зачем вам бандл? Вы что планируете подключать этот код где-то в другом приложении? Бандл это по сути интеграция вашего кода с симфони приложением.

Создавайте папку Api и туда помещайте. Можно сделать и отдельное приложение. Решать вам.

Цитата из документации:

В версиях Symfony до 4.0 было рекомендовано организовать собственный код приложения с помощью пакетов. Это больше не рекомендуется, и пакеты должны использоваться только для совместного использования кода и функций между несколькими приложениями.
Пакет похож на плагин в другом программном обеспечении, но еще лучше. Основные функции Symfony framework реализуются с помощью пакетов (FrameworkBundle, SecurityBundle, DebugBundle и т. Д.) Они также используются для добавления новых функций в ваше приложение с помощью сторонних пакетов.

Формы нужны там, где человек через UI вводит данные. А в AJAX (он же API) данные прилетают не в форму, а обычным POST запросом, который обрабатывается. И если надо валидируется с помощью компонента.

Подключите нормальный почтовик без ограничений и не выдумывайте.

Уведомления, чаще всего, должны быть практически синхронными иначе в некоторых из них теряется смысл. Используя ограничение 200 сообщений вы лишаете возможности человека получать актуальные уведомления при превышении лимита. Рано или поздно этот лимит будет много раз перекрыт и ваши уведомления никогда не дойдут до пользователя.

Кроме того, через почтовик могут быть и другие важные сообщения, например, восстановления пароля. Имея лимит — Ваши пользователи могут оказаться в той ситуации когда восстановить пароль не получится. И это будет не самым хорошим впечатлением отвалку системе, а так же не нужными сообщениями в службе поддержке.

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

Это всё не целесообразные вещи, в которые даже углубляться не надо. Почтовик без лимитов всё решит.

Все события агрегата должны помещаться в самом корне агрегата, как в варианте 1, но при этом метод который будет применять эти события должен вызываться после того как данные будут сохранить.

Другими словами в $eventsвы складываете все события при работе с сущностью-агрегатом, а в Handler проходите по этому массиву и отправляете в EventDispatcher каждое событие. Ну а там уже делаете подписчиков событий лога, если нужно. Главное, чтобы все события попадали в диспетчер после того, как данные будут сохранены в базу. Иначе может получится так, что возникла ошибка и сработала роллбек транзакции, откатив все изменения, а события при этом уже ушли.

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

Поэтому, что я вам посоветую. Поместить эту бизнес логику внутрь сущности в специальный метод. Например published(): void. Пример из кода.

https://github.com/Sylius/Sylius
https://github.com/ElisDN/demo-project-manager

Варианта два:

1. Разделить модули на бандлы
2. Разделить папками.

Первый способ достаточно популярный. Можете найти много вариантов на гидхаб, например Sylius. Но, я думаю, вам больше нужен второй. Создаете папку Model (Доменная модель). Туда помещаете весь доменный слой, в том чиле сущности и репозитории.

App\:
    resource: '../src/*'
    exclude: '../src/{DependencyInjection,Model/User/Entity,Model/Work/Entity,Migrations,Tests,Kernel.php}'

User и Work Модули.

Репозитории:

App\Model\User\Entity\User\UserRepository: ~
App\Model\Work\Entity\Members\Group\GroupRepository: ~
App\Model\Work\Entity\Members\Member\MemberRepository: ~
App\Model\Work\Entity\Projects\Role\RoleRepository: ~
App\Model\Work\Entity\Projects\Project\ProjectRepository: ~
App\Model\Work\Entity\Projects\Task\TaskRepository: ~

В переводах просто добавляйте 'translation_domain' => 'user' и ваш файл в переводах будет user.ru.yaml. Подробнее есть в документации.

Пример проекта есть на гитхабе