Спасибо за доклад. Интересная идея как использовать ValueObject из FluentValudator. К сожалению, предлагаемое решение не production ready т.к. оно не позволяет для поля вернуть сразу все ошибки при его валидации. Для полей типа пароля это важно. Лучше было меньше времени посвятить теории множеств, а больше - практичности подаваемого материала
Такие библиотеки как ErrorOr и Result позволяют возвращать список ошибок. Вполне можно провалидировать всю сущность и вернуть коллекцию ошибок + даже без использования библиотеки это можно реализовать
Спасибо большое за доклад :) Показалось немного странным решением выносить валидацию в AbstractValidator, который скорее всего будет проверяться в каком нибудь пайплайне медиатора только ради того, чтобы потом при создании еще раз провалидировать то же самое при фактическом создании обьекта абсолютно таким же образом) Я пока только новичок, но в чем плохо преимущество использования отдельно FluentValidation с их нормальным синтаксисом, ошибки которого возвращает нормальный список ошибок всей валидации Command и как последний эшелон защиты - уже саму валидацию в доменной модели без вот этих проверок на Result.IsFailure? Ну кроме разве что некоторого количества дубляжа кода, который похож по смыслу и небольшого overhead в поддержке двух мест для валидации (domain model и abstractvalidator)?
Как насчет делать валидацию через паттерн - спецификация? тогда не зависим от внешних либ + читаемость на уровне + можем переиспользовать правила для разных под-типов
так и не понял чем отличается VO от Доменного объекта. у доменного объекта тоже по сути нет идентификации (id) но эта индификация скалдывается из уникального набора данных (например серия и номер паспорта), но все таки это не ид. И если мы получим 2 граждан с одинаковыми серией и номером паспорта значит это один и тот же гражданин. но все таки граждананин, например, не VO (насколько я понимаю)
А чем номер паспорта не уникальный id? Как раз уникальность VO складывается из данных и могут существовать одинаковые VO, а одинаковых энтити не может быть
все равно странное итоговое решение использования валидатора..fluent validator по сути вендорный пакет и использование его должно быть в инфраструктурном слое. тут же показывается валидатор, и говорится что он уже в доменном слое. то есть при смене валидатора у нас это валидатор тоже будет изменен, то есть если он будет расположен в доменном слое то будет изменен доменный слой из-за смены fluent validator на какой то другой. или я что то не понимаю, или телега не едет.
Спасибо за системный и математический подход :)
Спасибо тебе, Человечище!
Спасибо, отличная презентация!!
Автор - красавчик! Есть чему поучиться
спасибо 👍
Это все хорошо и прекрасно, но самая сложная часть осталась не рассмотренной: а именно кросс-аггрегатная валидация.
Согласен, что если перед выполнением какой то операции нужно дернуть другой агрегат или вообще другой контекст?
зачёт
Спасибо за доклад. Интересная идея как использовать ValueObject из FluentValudator. К сожалению, предлагаемое решение не production ready т.к. оно не позволяет для поля вернуть сразу все ошибки при его валидации. Для полей типа пароля это важно. Лучше было меньше времени посвятить теории множеств, а больше - практичности подаваемого материала
Такие библиотеки как ErrorOr и Result позволяют возвращать список ошибок. Вполне можно провалидировать всю сущность и вернуть коллекцию ошибок + даже без использования библиотеки это можно реализовать
Спасибо большое за доклад :)
Показалось немного странным решением выносить валидацию в AbstractValidator, который скорее всего будет проверяться в каком нибудь пайплайне медиатора только ради того, чтобы потом при создании еще раз провалидировать то же самое при фактическом создании обьекта абсолютно таким же образом)
Я пока только новичок, но в чем плохо преимущество использования отдельно FluentValidation с их нормальным синтаксисом, ошибки которого возвращает нормальный список ошибок всей валидации Command и как последний эшелон защиты - уже саму валидацию в доменной модели без вот этих проверок на Result.IsFailure?
Ну кроме разве что некоторого количества дубляжа кода, который похож по смыслу и небольшого overhead в поддержке двух мест для валидации (domain model и abstractvalidator)?
Как насчет делать валидацию через паттерн - спецификация? тогда не зависим от внешних либ + читаемость на уровне + можем переиспользовать правила для разных под-типов
а бизнес правила как оформлять в валидацию?
Спасибо за доклад! А почему объекты новые мы создаём через метод Create, а не через конструктор(ы) ?
идея в том, что мы хотим вернуть результат создания Success/Fail, конструктор это не даст сделать, там можно только с исключением упасть
так и не понял чем отличается VO от Доменного объекта.
у доменного объекта тоже по сути нет идентификации (id) но эта индификация скалдывается из уникального набора данных (например серия и номер паспорта), но все таки это не ид. И если мы получим 2 граждан с одинаковыми серией и номером паспорта значит это один и тот же гражданин. но все таки граждананин, например, не VO (насколько я понимаю)
А чем номер паспорта не уникальный id? Как раз уникальность VO складывается из данных и могут существовать одинаковые VO, а одинаковых энтити не может быть
Приветствую, в заглавии ролика написано Validaton без i
Спасибо! Поправим
@@archdays ещё если есть возможность сообщите автору что на 49 странице опечатка. Пункт Инварианты.
все равно странное итоговое решение использования валидатора..fluent validator по сути вендорный пакет и использование его должно быть в инфраструктурном слое. тут же показывается валидатор, и говорится что он уже в доменном слое. то есть при смене валидатора у нас это валидатор тоже будет изменен, то есть если он будет расположен в доменном слое то будет изменен доменный слой из-за смены fluent validator на какой то другой.
или я что то не понимаю, или телега не едет.
про имя студнта в 25 символов "ф1утотй1381" валидное имя ? :)
Спасибо за интересный эфир! А где производить валидацию, если это примитивный тип?