JS: Предметно-ориентированное проектирование
2026-02-26 20:19 Diff
https://ru.hexlet.io/courses/js-ddd/lessons/validation/theory_unit

Обратите внимание на то, что CinemaHall создается с неверными параметрами. Что будет, если мы попробуем выполнить такой код? Он выполнится и репозиторий с удовольствием сохранит сущность, которая не должна существовать. Вряд ли такое поведение системы можно назвать удачным. Очевидно, что должен существовать дополнительный механизм, предотвращающий подобные ошибки. Этот механизм существует и называется "валидация".

Валидаций существует много разных типов, и делаться они могут на разных уровнях. Для начала давайте ответим на вопрос: А что необходимо валидировать? Первое правило валидации: никогда не доверяй пользовательским данным. Всё, что приходит из внешних источников, должно проходить валидацию. Даже если ваши пользователи это менеджеры, которые сидят в соседнем кабинете, это не повод им доверять. Хотя бы потому, что они могут ошибиться.

Второй вопрос связан с тем, а какая, собственно, валидация существует. Можно выделить следующие виды:

  • Клиентская валидация
  • Валидация сообщений
  • Валидация на уровне обработчиков
  • Валидация сущностей (Бизнес-Правила)
  • Ограничения на уровне хранилища

В этом уроке мы будем говорить про валидацию сущностей. Ту валидацию, которая отвечает за то, что наше представление предметной области находится в консистентном (согласованном) состоянии.

Yup

Yup — это простая и мощная библиотека для валидации объектов js. Из всего, что было на просторах сети, мне она показалась наиболее удачной, для наших задач.

Для её использования, первым делом необходимо описать схему валидации объекта (schema) с помощью функции yup.object. К каждому свойству привязывается набор ограничений. Каждое ограничение может быть настроено согласно документации. Например, ограничение min конфигурируется минимальным значением длины строки. Кроме того, как правило, в каждое из ограничений опционально можно передать сообщение об ошибке, которое будет выведено в случае если валидация не будет пройдена. Подробнее о том, какие правила встроены в Yup можно прочитать на официальном сайте.

Yup: check

Дальше на сконфигурированной схеме с правилами, можно вызвать синхронный метод validateSync или её асинхронный аналог validate (возвращает промис), в который нужно передать проверяемый объект. На выходе мы получаем либо объект, прошедший валидацию, либо будет выброшено исключение (в случае, если были обнаружены ошибки). Чтобы процесс валидации не прервался при первом несоответствии, необходимо в метод validateSync передать опциональное свойство abortEarly: false.

Теперь попробуем прикрутить эту библиотеку к нашей системе. Вот как это будет выглядеть:

Здесь есть пара тонкостей, про которые нужно сказать. Во-первых, массив с ошибками нужен, в том числе, снаружи, например для вывода сообщений об ошибках в формах. Во-вторых, мы не можем использовать функцию validateSync напрямую. Связано это с тем, что есть некоторые виды валидаторов, например uniqueness, которые проверяют уникальность сущности, делая обращения к репозиторию. А это значит, что валидатору нужен доступ к объектам репозиториям (ведь объекты мы храним в памяти). То есть в проекте появляется процесс инициализации, в рамках которого мы конфигурируем наш валидатор, передавая репозитории внутрь.

Обязательно изучите процесс инициализации приложения в практике к этому уроку

Такой подход к валидации, который подразумевает то, что сущность может быть создана в невалидном состоянии, не единственный способ организации валидации. Более того, в определённых кругах этот подход считается неверным. Я оставлю этот вопрос за рамками урока, но скажу так. На практике, в подавляющем большинстве проектов используются orm, валидация в которых устроена так же, как описано выше. Более того, ограничения, обычно, описываются прямо в самой сущности.

Собирая всё вместе