Владимир Хориков - Validation and DDD
Вставка
- Опубліковано 30 вер 2024
- Валидация - довольно большой топик. Существует множество библиотек и подходов к валидации, часто противоречащих друг другу. Сделать выбор в такой ситуации довольно непросто.
В этом докладе будет показано, как скомбинировать валидацию с практиками Domain-Driven Design, такими как Always-Valid Domain Model и Value Object pattern. Будет также показано, как использовать популярную в .NET библиотеку FluentValidation без нарушения DDD практик.
Примеры приведены с использованием C# и ASP.NET.
![Просто о сложном - Domain Driven Design [ru] / Дмитрий Науменко](http://i.ytimg.com/vi/7HXIrEsmlzM/mqdefault.jpg)
Это все хорошо и прекрасно, но самая сложная часть осталась не рассмотренной: а именно кросс-аггрегатная валидация.
Согласен, что если перед выполнением какой то операции нужно дернуть другой агрегат или вообще другой контекст?
Спасибо за системный и математический подход :)
Спасибо за доклад. Интересная идея как использовать ValueObject из FluentValudator. К сожалению, предлагаемое решение не production ready т.к. оно не позволяет для поля вернуть сразу все ошибки при его валидации. Для полей типа пароля это важно. Лучше было меньше времени посвятить теории множеств, а больше - практичности подаваемого материала
Такие библиотеки как ErrorOr и Result позволяют возвращать список ошибок. Вполне можно провалидировать всю сущность и вернуть коллекцию ошибок + даже без использования библиотеки это можно реализовать
Спасибо большое за доклад :)
Показалось немного странным решением выносить валидацию в AbstractValidator, который скорее всего будет проверяться в каком нибудь пайплайне медиатора только ради того, чтобы потом при создании еще раз провалидировать то же самое при фактическом создании обьекта абсолютно таким же образом)
Я пока только новичок, но в чем плохо преимущество использования отдельно FluentValidation с их нормальным синтаксисом, ошибки которого возвращает нормальный список ошибок всей валидации Command и как последний эшелон защиты - уже саму валидацию в доменной модели без вот этих проверок на Result.IsFailure?
Ну кроме разве что некоторого количества дубляжа кода, который похож по смыслу и небольшого overhead в поддержке двух мест для валидации (domain model и abstractvalidator)?
спасибо 👍
Спасибо тебе, Человечище!
Спасибо, отличная презентация!!
Как насчет делать валидацию через паттерн - спецификация? тогда не зависим от внешних либ + читаемость на уровне + можем переиспользовать правила для разных под-типов
Автор - красавчик! Есть чему поучиться
про имя студнта в 25 символов "ф1утотй1381" валидное имя ? :)
а бизнес правила как оформлять в валидацию?
так и не понял чем отличается VO от Доменного объекта.
у доменного объекта тоже по сути нет идентификации (id) но эта индификация скалдывается из уникального набора данных (например серия и номер паспорта), но все таки это не ид. И если мы получим 2 граждан с одинаковыми серией и номером паспорта значит это один и тот же гражданин. но все таки граждананин, например, не VO (насколько я понимаю)
А чем номер паспорта не уникальный id? Как раз уникальность VO складывается из данных и могут существовать одинаковые VO, а одинаковых энтити не может быть
Спасибо за доклад! А почему объекты новые мы создаём через метод Create, а не через конструктор(ы) ?
идея в том, что мы хотим вернуть результат создания Success/Fail, конструктор это не даст сделать, там можно только с исключением упасть
зачёт
Приветствую, в заглавии ролика написано Validaton без i
Спасибо! Поправим
@@archdays ещё если есть возможность сообщите автору что на 49 странице опечатка. Пункт Инварианты.
все равно странное итоговое решение использования валидатора..fluent validator по сути вендорный пакет и использование его должно быть в инфраструктурном слое. тут же показывается валидатор, и говорится что он уже в доменном слое. то есть при смене валидатора у нас это валидатор тоже будет изменен, то есть если он будет расположен в доменном слое то будет изменен доменный слой из-за смены fluent validator на какой то другой.
или я что то не понимаю, или телега не едет.
Ты ничего не понял. Код валидаций в доменном слое, первое применение валидаций в Presentation слое.
Спасибо за интересный эфир! А где производить валидацию, если это примитивный тип?