Есть такие задачи которые должны быть выполнены последовательно. И в метод нужно передать 5-10 источников данных

Ну в данном случае заполнение сущности не имеет последовательности.

Но ивентовая архитектура выглядит как так сказать - более путанней)

Особенно когда не сайд эффекты а основные действия в ней выполняются

Т.е вам нужно будет прокинуть ЗаполнятельСущности в хендлер. Либо же бросить ивент - заполнисущность?

А как потом получить ответ от события? А синхронно или нет ?

В общем имхо это усложнение ненужное.

зачем ответ. Если что-то не так - исключение.

В астнхронке? А толку ?

Имхо такой метод при обработке формы идея плохая

я не про очереди и тп, обычный обсервер . Т.е. синхронно

Имхо это ненужное усложнение банальной обработки формы

Либо я неправильно представляю себе вашу идею

Понял принял вашу мысль, спасибо :) но зависимотсти в тестах - боль...

Вот представим есть пользователь. У него есть соц сети, какие то интересы и много всего со связью о-м.  Страница его регистрации/ плюс редактирование. Я чтобы не завязываться на пользователе и его не перегружать вынес это в сервисы в тех сущностей, т.е. сервисы интересов и соц сетей (это спорно но и не особо влияет на вопрос).  Но для обработки все равно понадобятся какие то хэндлеры - корректность соц сети и т.д., что-то еще. Чтобы это было в едином месте, а не дважды в реге и редактировании профиля.  В итоге в командаъ рег/edit - куча сторонних хэндлеров. Плюс огромный код в самой команде.
Как вариант, вместо эти хэндлеров прокинуть ивент, на который эти хэндлеры (которые дополнительные для проверки связей и т.д.) были бы подписаны.  И уже делали свое дело в рамках своего "контекста". Т.е. доп. хэндлеры бы утекли из основного обработчика.

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

Прилетают ids связей. Это проверяется только запросом в бд, значит надо подтягивать репо сторонней сущности, как зависмость.  Таких связей о-м - несколько. Уже несоклько сторонних репо. Их надо все мокать в каждом тесте да еще и самих проверять на ожидание и эммулировать возврат.

Весь вопрос даже может не в одних тестах, а в их хрупкости и больном построении.

Вообще идея взята отсюда:
https://blog.thecodewhisperer.com/permalink/you-dont-hate-mocks-you-hate-side-effects

потому и сыпятся, потому что тестируете непонятно что ради просто чтобы тесты были...