В предыдущих частях (раз, два) мы уже добились того, что наша доменная модель полностью защищена и в случае попадания невалдиных данных наше приложение будет кидать
Exception в любой непонятной ситуации. ❗️ Это круто работает если нам надо прервать какую-то операцию, но не слишком удобно, если мы хотим показать пользователю ошибки, особенно если их несколько (например при заполнении формы).
❌ Первое, что приходит в голову, это добавить валидацию в контроллер. При этом у нас уже есть готовые
Value Object's, которые используются и доменном слое! Что нам мешает провалидировать Email? Мы точно будем знать, что изменив правила валидации в одном месте, они изменятся везде. С одной стороны мы убрали дублирование, с другой нет. Мы начинаем переносить всю бизнес логику в контроллер и подсознание говорит, что мы делаем что-то не так. И не надо так делать!
📌 Нам надо просто убедиться, что пользователь не ошибся при вводе данных
👉 Мы должны сделать всё от нас зависящее, чтобы помочь пользователю это сделать. Пока пользователь вводит свои данные — вы уже можете выдать предупреждение, что
email выглядит некорректно.👍 Такую валидацию вы можете доверить фронтовой части вашего приложения (да-да, вообще убрать из контроллера❗️), если работаете c
Vue, React, etc..., или доверить встроенным валидаторам фреймворка, если используете twig, blade, etc... Главное помните, что ваша задача помочь пользователю, а не ввести его в ступор своими правилами.📌 Но есть более сложные бизнес требования
👉 Например во время заказа, вам нужно проверить, что на складе всё еще есть хотя-бы одна единица товара, которую заказывает пользователь (ведь пока он чехлился, кто-то другой мог забрать последнюю единицу первее чем он нажал кнопку). Такие проверки должны выполняться в application слое приложения и отлавливаться через
Exception'ы.📌 Исключения обязательно нужно контролировать
Некоторые, должны быть видны только разработчикам, потому как раскрытие этих данных пользователю сразу создаёт угрозу безопасности. Другие, такие как исключения бизнес логики, должны быть информативными для ваших пользователей.
📌 Вам обязательно нужно различать их в своём коде.
💁♂️ Первые могут возникать, когда кто-то пытается абузить ваше приложение, например отправляет рандомные данные
POST в обход формы. Такие ошибки должны быть отловлены в инфрастуктурном слое, информация обязательно отправлена в логи, а на фронт выброшен 400 (или более подходящий) ответ без какой-то конкретики. Чтобы не дублировать подобный код в каждом контроллере — настройте перехватчик в
production среде на уровне вашего фреймворка (для development окружения их "глушить" не нужно).👍 Для вторых круто будет создать пользовательские классы исключений, которые можно отлавливать вместе с другими ошибками формы и отправлять на вывод пользователю. Логированием таких ошибок можно пренебречь, но опять же, всё зависит от вашей задачи.
👉 Использование исключений для пользовательской валидации не должно быть в приоритете. Помощь пользователю при работе с пользовательским интерфейсом — лучший способ пользовательской валидации 😉.
#php #oop #validation #middle #source
