Че я думаю по итогу. У нас есть несколько вариантов вхождения в метод службы:
1. апи эндпоинт, принимает какие-то данные
2. внутренняя логика, которая эти данные как-то генерирует

У нас есть ДТО (для АПИ = контракт), которая создается по определенным правилам (типы, required поля и т.д.)
Во время создания ДТО мы можем развалиться.

Если мы хотим исчерпывающий отчет по ошибки для случая 1 - валидируем входные данные на момент соблюдения контракта до создания ДТО
Если человек по каким-то причинам создает невалидную ДТО в рамках внутренней логики - он получит ошибку процесса маппинга на ДТО, захочет - обработает

Дальше у нас идут правила, которые должны быть соблюдены для корректной работы метода службы. Их можно делать как через VO, возможно можно делать их через validate->(DTO) на входе и т.д.

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

Шо скажемс?

все становится проще если на каждом уровне смотреть на валидацию с позиции "а кому это надо".

Валидация "email не должен быть пустой" - это валидация входных данных и должна она происходить на "входе". До того как ты эти данные успеешь замэпить на что-то и т.д.  Можно мэпить на DTO и валидировать если у тебя мэппинг 1:1 - иначе потом сложно понять где проблема.

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

На каждом уровне есть клиентский код который чет вызываает и на каждом уровне свои правила. + есть разница между "валидацией данных" и "проверкой инвариантов стэйта".

Словом... вся проблема в излишнем обобщении

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

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

В ямликах храни

В ямликах храни

Так в ямликах - хранение валидации классов, а нужно провалидировать массив. Правда если в валидатор есть экспорт рулов, то уже все гораздо интереснее.

Но чем не устраивает мапинг на ДТО и валидация дтохи?

catch никто не отменял
как и дефолтные значения

Или в самой DTOхе писать, но в методе, чтобы можно было экспортнуть. Хотя если покопаться, наверное можно и аннотации дернуть. Просто я думаю делают как то более изящно ) колитесь ))

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