Валидация данных на уровне бизнес-логики приложения

Данная статья продолжает тему статьи «Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя».

Во многих бизнес приложениях для сущности User выдвигается стандартное требование: «При регистрации пользователя нужно проверять, что записываемый email уникальный, ни у одного другого пользователя такого больше нет».

Подобная задача предельно типовая и поэтому должна иметь типовое решения. Далее рассматривается решение, основанное на трёхслойной архитектуре, в которой каждый слой (layer) состоит из трёх подслоёв (sublayer). Такая архитектура была описана в статье «Пример описания многослойной архитектуры, основанной на использовании наборов подслоёв и иерархии моделей данных».

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

При получении запроса функционал веб-сервиса десериализует данные пользователя в объект типа UserDTO. В этом объекте в поле Email находится адрес электронной почты нового пользователя. Этот адрес электронной почты должен быть уникален на уровне соответствующего поля таблицы Users, в которой в базе данных хранятся данные пользователей приложения.

Схема работы приложения для use case создания нового пользователя представлена на рисунке.

Внешний запрос к веб-сервису на создание нового пользователя обрабатывается в facade layer и далее идёт вызов функционала application service, который является фасадом бизнес-логики приложения (logic layer).

Use case создания нового пользователя реализуется в виде двух вызовов функционала logic layer.

1. Application service вызывает функционал объекта типа EmailValidator для валидации адреса электронной почты нового пользователя приложения.

2. Если валидация прошла успешно, то application service вызывает функционал persistence service для вставки данных нового пользователя в базу данных.

Объект типа EmailValidator реализует следующий функционал.

1. Проверяет значение из поля Email объекта типа UserDTO на соответствие формату адреса электронной почты.

2. Вызывает функционал persistence service для формирования запроса к базе данных для проверки уникальности значения из поля Email объекта типа UserDTO на уровне соответствующего поля таблицы Users, в которой в базе данных хранятся данные пользователей приложения.