Это только для образа, чтобы понимать принцип работы
У меня мало опыта на симфони)

так если item.id = 2, то должно сработать
session[item.id]

Верно

Привіт
Є концептуальне питання
Проект на Сімфоні
В проекті ми ведемо лог дій користувача
Лог-таблиця є найбільшою
Питання -
лог-таблиця гальмує проект в цілому?
чи розумно зберігати лог в одній базі з іншими даними?
чи варто винести в окрему базу?

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

Всем доброго дня. Сейчас у меня толстые контроллеры. Хочу выделить use case и вызывать их из контроллера. В какой папке их лучше организовать? Думаю создать папку UseCase и в ней подпапки с контекстами:

/UseCase/Context1/UseCase1.php

и тп.

Нормальное ли это решение на ваш взгляд? Как вы это делаете в своих проектах?

src/Module1, src/Module2

В папке domain или model.
Это же юзкейсы доменной области

Домен это сущности, use case отделять надо от них

Так понимаю надо:
/Context1/Domain - сюда сущности а варианты использования сюда:
/Context1/UseCase/

usecase - это слой приложения
Context1/Application/UseCase/*

Типо гексагональная архитектура получается

Да, вот так точнее

Ребят, а чем я рискую если обычно делаю так
1) слой инфраструктуры
2) сервисный слой
3) domain
- usecases
- domain entities
4) слой данных

Где слой сервисов - это что-то вроде фасада для usecase. Как пример это регастрация пользователя через кафку, http, консоль. Сервисный слой предоставляет удобный интерфейс для эндпоинтов приложения, а сам использует один и тот же RegistrateUserUseCase.

И второй вопрос, можно ли  вызывать несколько usecase друг за другом, допустим паттерн pipeline?

(Pipeline ложится на сервисный слой, а сами шаги используют usecase)

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

pipeline паттерн обычно используется не как инфраструктура, а как часть языка, то есть его расширение... этакая новая семантика наряду с if/else

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

Ну на каком нибудь js или elixir да. Но в php это или либа или часть фреймворка типо workflow. Поэтому я и хочу переложить это на сервисный слой.
Как итог ваш подход это
HttpModule -> UseCase -> Domain
А мой:
HttpModule -> HttpModuleServices -> DomainUseCases

И особой разницы нет

не важно в каком языке