ничто не мешает какому-то Васяну добавить модуль, который будет собирать даные с АПИ, создавтаь из них ДТО и без валидации отправлять мне в метод

то есть невалидные данные появляются только там, где твоя система взаимодействует с внешним миром, да?

это один из кейсов, ничто не мешает какому-то Васяну в крон команде создать невалидный ДТО и отправить мне в метод

Ваш метод должен внутри себя такое предотвращать. Это БЛ, а если не БЛ - то это просто данные, которые впринципе и должны быть любые.

по такой логике - никто не мешает тому же васяну просто убрать всю валидацию на проекте

Давайте лучше пример невалидного ДТО и метода

+

перед тем, как что-то менять или удалять - 10 раз подумает (если уж совсем не Василий), а забыть добавить / пропустить требования - запросто

если исходить из того, что у тебя в команде работают либо враги либо долбоёбы - выхода нет вообще.

никто не помешает тому же васяну в методе do просто всё сломать кху ям.

Тут просто такой момент, ваша логика должна быть жесткая и без этой валидации. Просто с ней ваш метод не упадет по 500, а отдаст красивый результат.

@vixtrime в целом вы правы. Но делают и так и так, прям критичного - вроде как нет.

Просто еще есть момент как сделать по красоте валидацию.
Например мы перегоняем массив в ДТО и при этом у нас невалидный массив, например некоторые поля не проставлены, а в конструкторе ДТО они обязательны.
По хорошему кинуть ексепшон со всеми ошибками по всем отпавшим required полям если их больше 1, но сериализатор отпадет на первом же поле и нужно будет из него брать ошибку и она будет только для одного поля.
Соответственно если это приемка данных извне, то нужно валидировать перед маппингом на ДТО для обеспечения нормального создания ДТО, а потом ДТО уже влидировать по правилам, которые требует юз кейс.
В сухом остатке получается два слоя валидации.
Шо скажемс?

Несколько слоев валидации - это норм. Другое дело на сколько внутренняя валидация должна быть жесткой и дублирующей. И нужно ли оно вообще. Просто по хорошему БЛ должна быть зашита именно в самих бизнес объектах, а не где то в валидаторе и его правилах.

Если же говорить о ваших же мыслях, что точка правды должна быть одна. А если она будет в валидаторе - то их будет много, так как методов может быть несколько которые работают с опредленными объектами

Ну первый слой валидаторов работает только для того, чтобы сами ДТО создавались и в случае чего создавалось исчерпывающее исключение, что ДТО не может быть создан, а специфические правила, как, например типа строки email ,должны проверяться уже непосредственно в службе

Почему Email не может быть объектом-VO, чтоб его попросту нельзя было создать невалидным?

И служба не будет париться с регулярками, а будет заниматься делами

Короче я потерялся в тоге к чему мы пришли :) Соглашусь, что лучше сначала валидировать массив. (В симфони можно кстати формы использовать под это дело) . Далее конкретно в валидации особо смысла не вижу. Там уже должны быть бизнес правила и они все отрубят жестко.

А если у нас непосредственно перед созданием VO нужны выполнить ресурсоемкие операции? Например запрос в БД или запрос на АПИ? Мб имеет смысл валидировать input, а потом уже начинать его обрабатывать?