Зачем нужны дата трансфер обекты и билдеры ?

Привет

Вопрос основан на опыте работы с laravel где есть FormRequest для проверки дынных которые пришли из формы, но что то подобное есть и в симфони и можно вообще этот этап заменить просто проверкой в контролере на чистом php, суть вопроса не изменится.

В проекте переиодически натыкаюсь на использование билдеров и DTO для меня это выглядит очень странно потомучто вся валидация происходит в FormRequest, потом как установка данных которые пришли из реквеста в DTO а из DTO мы добавляем данные в модель и потом сохраняем те DTO(некоторый data transfer object) какойто странный промежуточный шаг. С билдерами примерно тоже самое, если я правильно понял.

Зачем тогда вообще нужны билдеры и ДТО, это не нужный лишний шаг для меня если можно напрямую данные из реквеста сохранить в модель тк они уже прошли проверку в FormRequest ?

Я не видел как это у тебя там делается, поэтому просто отвечу на вопрос из заголовка про DTO.
Зачем оно вообще надо. DTO - некий контейнер для данных. По сравнению с передачей данных в виде массива есть определенные плюсы. Можно валидировать данные в конструкторе DTO. Данные строго структурированы и типизированы. То есть в любом месте клиентского кода принимая DTO ты можешь напрямую вызывать методы ValueObject включенного в него. Без всяких isset и тому подобного набора проверок(tell don't ask). Это мы уже проверили в конструкторе. Один раз написали DTO и формируем его где нам надо. Не всегда данные приходят из формы. Возможно та же самая логика будет также запущена в каком-нибудь cron скрипте или импорте из xls файла. Во всех местах формируем один и тот же DTO, но из разных источников и разных первоначальных структур данных. И далее его передаем в тот же сервис обработки. Логика одна, а источники данных разные.
Это не все что можно сказать по теме.
Вот для ознакомления - https://www[dot]youtube[dot]com/watch?v=rjtbCyacJas (не воспринимать буквально как библию, это только для ознакомления)
И на закуску про ассерты(в конструкторе DTO удобно) вот это например https://www[dot]youtube[dot]com/watch?v=8v02-XPm3Do
(Добавление)
А вообще подобными вопросами частенько задаются думающие новички. На простых проектах что-то кажется лишним. Более сложные проекты требуют большей гибкости. Но ничего не дается бесплатно. Платим сложностью кода.

Этими dto-шками в слоистых архитектурах переходят границы.
Поищите про чистые архитектуры, гексогональные, луковые.

Dto не имеет отношения к слоеной архитектуре. И к гексагональной тоже. Это вообще не про архитектуру, а про структурированность и типизацию.

передавая скаляры и массивы мы вынуждены проверять данные в каждой точке приема
DTO переносит проверки в одну точку - формирование DTO
+ можем сразу юзать методы объектов входящих в DTO без instanceof
как это может переходить границы я не понимаю