тогда не понял, как вы предлагали. Тут же фильтрация и есть.

Или это не внутри агрегата?

Да, снаружи

Если данные готовятся исходя из данных агрегата, то это должен делать агрерат

Еслм агрегату нужно обратиться к другим частям - он кидает сообщение и ждёт результата

Ну немного не то имел ввиду: у меня был огромный юзкейс с кучей репозиториев чего то там еще, но по факту они все готовили данные типа из ID реквеста получить сущность и т.д.  Я разнес по декораторам и в главный класс прилетают уже  данные готовые для употребления агрегатом.  Тем самым меньше моканья при тестах и разбито на кусочки мелкие. Хотя мб и херня вышла))

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

Какая разница куда ты что разнес? Главное что все решения о данных агрегата делает агрегат

Ну у меня прилелетает int:category_id а мне для агрегата нужен Category. Я его в другом классе из репозитория достаю, а не в основном юзкейсе

Тем самым избавляюсь от зависмости

А зачем ему нужна категория?

У меня нет отдельных типов по id, сделано по простому $agr->setCategory(Category).

Сколько полей в агрегате? И строк кода?

5 обычных инпутов, 4 м-о, 4 о-м

Я говорю про проперти агрегата.

5+4+4 если я правильн понимаю

или про обычные свойства без связей?

Про все  свойства. Просто скорее у тебя проблемы с разделением. Если тебе нужно много связей.

у меня сущность "услуга"
У нее свои мелкие свойства, а потом пошли связи:  владелец, тип(категория), город, соц сети, ссылки на ютуб, галерея фото. Коллекции хранятся в "услуге". Я бы срадостью вынес коллекции но не понимаю, как тогда работать с коллекцией вне агрегата, так как есть всякие штуки типа "нельзя 2 ссылки на одну соц сеть", "должна быть минимум одна картинка". Можно вынести в какой нить сервис класс - но тогда надо плотно работать с репозиторием будет и не потестировать без него.

строишь приложение с подходом "приложение = чистая функция"? 🙂