Приветствую. Встал вопрос. Есть ли вообще смысл валидировать обьекты, например

DTO, используя подход:
заполнить данными -> validate(object) ?
По сути, что это значит - мы создаем обьект, который, потенциально, может быть создан в невалидном состоянии и если он не будет провалидирован, то дальнейшее поведение основанное на это обьекте может строиться с использованием невалидного состояния обьекта, чего мы желаем ибежать

Есть такой подход. Но тут скорее первичная валидация, дальше должна быть валидация внутри бизнес объектов

Ну это не дает ответа на вопрос. Так ли это, что с таким подходом мы создаем невалидный обьект? И что мы должны избегать это

Банально создают валидирующий мидлвар (вроде даже в самой симфе сразу есть), который валидирует команду мессенджера. Т.е. не сам хадлер валидирует а бас

Ну если мы что-то проверяем на валидность, значит уже сам факт есть, что объект может быт невалидный.

кстати на счет места валидации, как по мне - оно должно быть одно например у нас есть служба с методом do метод do принимает doDTO и для корректной работы метода она должна быть валидной т.к. метод do могут вызвать из любого места приложения - валидация входящих в метод параметров должна ложиться на плечи самого метода соответственно валидация на верхних слоях приложения становится ненужной / нежелательной нежелательной потому что разносить валидацию по сути одного и того же по слоям - плохо шо скажемс?

у тебя в любом месте приложения могут ВНЕЗАПНО возникнуть невалидные дто? или же только в тех местах, где юзеры тебе засылают свои запросики?

Звучит логично, тоже задавался этим вопросом. Тут правда момент, что это первичная валидация, скорее чтобы фронту отдать данные и мессаджи. Внутри все логика "валидирует" в своих процессах

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

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

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

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

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

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

+

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

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

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