Валидация и бизнес-правила

Данная статья - чисто мое субъективное мнение (имхо).

Я предлагаю различать в сайтострое два понятия - валидация данных и бизнес-правила.

Валидация - это проверка на совпадение ожидаемого значения с полученным от пользователя.

Бизнес-правило - это наши ограничения на валидные значения.

Обычно правила валидации безусловные и простые, в то время, как бизнес-правила почти всегда нетривиальные.

Ниже будут конкретные примеры относительно сайтостроя, но вот абстрактный: приходишь в магазин за телевизором. Прямо там ты можешь проверить, что он включается и что-то показывает (валидация полей формы). Принес домой, проверил подключение к твоему wi-fi, кабелю, повесил на стену - не упал, дверью не закрыт, цветам не мешает, кошаков не пугает (проверка бизнес-правил).

Тут тонкая грань. И я не раз сталкивался с ситуацией, когда не мог отличить одно от другого. Зачем вообще отличать? Хотя бы для того, чтобы архитектуру приложения не ломать. Например, когда валидаторы лезут в БД за данными - это крайне хреновая ситуация. Пробиваем все слои приложения, от слоя представления (presentation) напрямую в базу (data layer). Жесть..

Примеры

#1: Email

Самый популярный пример: регистрируем юзера, проверяем email на корректность и уникальность. Первая проверка - это забота валидаторов, а вот проверка уникальности - это уже бизнес-логика. И она не должна жить в модели формы, или что там у вас занимается валидацией.

Поробую объяснить. Проверка на правильность - это простое безусловное утверждение, самодостаточное, если угодно. Мы ожидаем, что передано будет что-то похожее на email. Всё.

Проверка на уникальность email - это уже наши ограничения. Например, мы хотим искать среди активных записей и если добавляем админа, то искать среди админов, иначе среди любых других типов юзера. Это - бизнес-правило. Могу еще сюда добавить: будем проверять мыло на список черных mail-серверов - это еще одно бизнес-правило. Т.е. мы решаем, что считать запрещенным мылом.

Еще раз: мы ожидаем что-то похожее на email - валидация, у нас есть требования к такому мылу - бизнес-правила.

У разделения на валидацию/бизнес-правила есть еще одно преимущество. Допустим, мы хотим логировать попытки зарегистрироваться с существующем мылом. Если запихать все проверки в механизм валидации, то потом будет проблематично оттуда вести лог. А если проверка уникальности выделена в бизнес-правило (некий сервис, например), логирование оттуда - не проблема. Хотя это конечно зависит от конкретного движка.

Пример движка, позволяющего смешать мух с котлетами - Laravel. У него есть валидатор уникальности некоторого значения среди данных из базы. Однако нужно понимать, что наличие такой возможности еще не требование так поступать. Т.е. движок неплохой, просто он позволяет творить зло. Какую выбрать сторону - это ваше решение.

#2: Текст для поиска

Форма поиска. Есть поле для произвольного текста. Мы хотим ограничить переданный текст по длине - валидация, и выкинуть из поисковой строки короткие слова - бизнес-правило. Т.е. мы ожидаем, что текст будет не длинее NN символов; и нас есть свои требования к такому тексту - слова не короче N символов.

Это не надуманный пример, я сам столкнулся с проблемой, как правильно все описать в поиске на этом сайте. И на практике у меня еще одно требование - если поиск в заголовках, то нет ограничений на длину слов; при полнотекстовом поиске - есть ограничения. Я подзаколебался придумывать правильную валидацию под все это, пока наконец не вынес зачистку коротких слов в сервис. И все встало на свои места.

#3: Диапазон значений

Реальный пример, из другого проекта. Есть пациент, мы знаем его дату рождения. В отдельной форме врач заполняет данные о вредных привычках пациента. Скажем, вводит даты, когда пациент курил. Там два поля с годами, от и до.

Валидация тут:

• убедиться, что введены 4 цифры, похожие на года;
• дата "от" должна быть раньше даты "до".

Все это вполне ожидаемо.

Бизнес-правило: мы считаем, что пациент не мог начать курить раньше 3х-летнего возвраста. Я понимаю, курящий пупсик - звучит дико, но вот такие у нас ограничения. Если мы потом решим, что до школы он не мог пристраститься - это все равно наше ограничение, т.е. бизнес-правило.

#4: Формат даты и ее реальность

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

Если же нам нужно, чтобы дата была до нашей эры или из последнего десятка лет - вот это уже бизнес-правило.

Надеюсь, понятно все расписал :) Повторюсь еще раз: необходимость разделять валидацию входящих данных и бизнес-правила - это мое личное мнение, никому не навязываю.

[UPD] Я вроде бы придумал простой способ отличать валидацию от бизнес-правил: если пользователь обладает всей информацией, чтобы ввести значение правильно - значит это вопрос валидации. А те ограничения, которые он сам проверить не может - это бизнес-правила.

Это расходится с тем, что в статье написано. Мысль еще сырая, я пока пытаюсь ее применить на практике.