Блог

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

Я выполняю проверку в моделях домена, например, при создании нового события (). Конструктор выполняет базовую проверку для переданных значений, таких как имя, не может быть нулевым или пустым. Но когда дело доходит до написания теста для этого, я начинаю сомневаться, должна ли логика проверки находиться в службе домена, которую можно тестировать индивидуально для проверки. Затем этот метод можно протестировать, чтобы убедиться, что все зависимости вызываются правильно. У меня возникает вопрос, является ли это утечкой домена на уровень приложения или это считается логикой уровня приложения. Но в то же время домен не несет ответственности за получение DTO и проверку значений, правильно?

Я обычно задаю вопрос: это что-то, что пользователь мог сделать неправильно, или что-то, что разработчик, реализующий против API, мог сделать неправильно?. Под последним я подразумеваю, что разработчик, реализующий API, не должен был разрешать пользователю отправлять какой-либо неполный запрос в первую очередь.

Если ваш API строго определяет, что свойство должно быть установлено (т. Е. Является Обязательным)Я бы уже проверил это на уровне API или приложения. Нет необходимости передавать это на уровень домена. Поэтому, если разработчик, который внедрил API (например, во внешнем коде), забыл убедиться, что отправленные данные соответствуют спецификации, ошибка должна возникать уже при получении и обработке данных из вызова REST, сообщения из очереди или любого другого используемого протокола связи. Я, конечно, говорю об инвариантах, которые не связаны с бизнес-логикой на этом уровне.

Это, конечно, не означает, что в некоторых случаях что-то подобное также будет проверяться на уровне домена. Классы модели домена не должны допускать создания с недопустимыми данными, поэтому возникновение ошибки при получении недопустимых свойств также будет являться обязанностью уровня домена.

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

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

Является ли плохой практикой иметь проверку в службе приложений, которая проверяет, является ли идентификатор DTO действительным или если одно из свойств dto является пустым?

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

Хотя существуют разные представления, связанные с проверкой на каком уровне, я лично считаю, что на уровне домена следует проверять только бизнес-правила. Включение каждой проверки на уровне домена приводит к неправильному уровню домена. Уровень домена предназначен для бизнес-правил. Проверка свойства, которое просто не должно быть пустым, является бизнес-правилом? Если нет, было бы лучше проверить его на уровне службы приложений.

Как видно из службы заказа, которая является примером проекта Microsoft, такого рода проверки реализованы на прикладном уровне. В этом примере CreateOrderCommand это похоже на DTO. В нем используется FluentValidation. Из-за принципа единой ответственности я рекомендую вам использовать этот инструмент, чтобы отделить процесс проверки от вашего метода и значительно упростить тестирование.