Короче я потерялся в тоге к чему мы пришли :) Соглашусь, что лучше сначала валидировать массив. (В симфони можно кстати формы использовать под это дело) . Далее конкретно в валидации особо смысла не вижу. Там уже должны быть бизнес правила и они все отрубят жестко.
Че я думаю по итогу. У нас есть несколько вариантов вхождения в метод службы:
1. апи эндпоинт, принимает какие-то данные
2. внутренняя логика, которая эти данные как-то генерирует
У нас есть ДТО (для АПИ = контракт), которая создается по определенным правилам (типы, required поля и т.д.)
Во время создания ДТО мы можем развалиться.
Если мы хотим исчерпывающий отчет по ошибки для случая 1 - валидируем входные данные на момент соблюдения контракта до создания ДТО
Если человек по каким-то причинам создает невалидную ДТО в рамках внутренней логики - он получит ошибку процесса маппинга на ДТО, захочет - обработает
Дальше у нас идут правила, которые должны быть соблюдены для корректной работы метода службы. Их можно делать как через VO, возможно можно делать их через validate->(DTO) на входе и т.д.
Как итог: обьект (инстанс службы) через свой метод (проверки вызываемые в нем) должен проверять правила требуемые для конкретного юз кейса. Таким образом, как по мне, дубликация правил валидации на обоих слоях будет сведена к минимуму и риск некорректной работы сервиса тоже.
Шо скажемс?
