Всем привет, сегодня я расскажу  как и зачем я структурировал валидацию в Laravel. Form Request - это класс где мы описываем правила валидации для входящих данных. Обычно  класс содержит набор правил под запрос из клиента. Мы можем его декларировать в контроллере, и через контейнер в Laravel  он автоматически проверит данные на соответствии нашим правилам и через внутренние механизмы фреймворка выдаст ответ клиенту. Для примера нам надо обновить профиль пользователя. Form Request может выглядеть вот так: Выглядит знакомо и ничего не обычного. Схематично я нарисовал ниже как это выглядит. Все правила в одном Form Request являются неразделимыми и вроде это как не должно быть проблемой... Но, давайте представим, что мы разрабатываем телеграм бота и функция обновления пользователя необходима и здесь. Взаимодействия пользователя через бота несколько отличается от привычного взаимодействия пользователя на сайте. Бот задает последовательные вопросы, в момент получает ответы и сразу должен их провалидировать. Будет странно - если  в конце бот сообщит "еmail был не верный". В моем представлении бот ведет диалог, вопрос за вопросом, контролируя верность введенных данных. Итак у нас уже есть один Form Request который валидирует обычную форму из сайта. Мы можем постараться изменить наш Form Request под нашу задачу. Добавить необязательные правила(но это шанс из формы не отправлять все данные). Еще мне не нравится этот подход, так как он двухсмысленнен и нечитаем. Вне контекста мы(или коллега) позже не вспомним что валидируется и при каком случае. Добавить обычную валидацию. Тут есть нарушение принципа "Don't repeat yourself". Если у нас добавиться новое правило(а оно обязательно будет), то нам надо не забыть его изменить уже в двух местах. Мне в голову пришла другая идея, рассматривать каждое поле(field) как отдельное ValidatorValue. Начнем с того как будет выглядеть наш предыдущий Form Request.   Мы отнаследовались от моего базового  класса FormRequestDecompose, который содержит в себе некую логику по обработки объектов ValidatorValue. В список правил, мы добавляем теперь просто объекты. Этот способ не исключает обычное использование ключ и список правил в виде массива(для примера) Каждый класс реализует интерфейс ValidatorValue. В конструктор передаются внешние данные на которые мы можем опираться во время валидации. Еще в конструктор я передаю атрибут, если он может изменяться, но это зависит уже кода. В методе getRules описывается набор правил валидации, соответственно в методе getMessages кастомизированные ответы на эти правила(если они имеются). Как теперь мы можем решить нашу проблему с валидацией данных от бота?  В Laravel я использую BotMan, это фреймворк для работы с ботами и заточенный под Laravel.Итак, в моем случае использую Facade для валидации. Все нужные данные и конфигурации мы передаем из нашего объекта. К сожалению, это не тот клиентский код о котором мы мечтали.Но мы можем написать небольшую обертку и  выглядеть это будет более изящно: Стоит упомянуть, что как и во фреймворке, я предварительно регистрирую в контейнере FormRequestDecompose, для его корректной работы. В этом подходе мне нравится, что все правила находятся в одном месте. Мы можем его использовать как в Form Request так и при обычной валидации. Во-вторых название класса может быть более выразительным для предметной области, например: ConsumerEmail, SellerPersonalPhone. Специально для ленивых и любознательных я создал репозиторий.  Код там довольно простой, поэтому можно просто адаптировать его под себя. Если вы сталкивались в своей практике с похожей проблемой, напишите в комментариях как ее решали.