Спасибо за системный и математический подход :)

Спасибо тебе, Человечище!

Автор - красавчик! Есть чему поучиться

Спасибо, отличная презентация!!

спасибо 👍

Это все хорошо и прекрасно, но самая сложная часть осталась не рассмотренной: а именно кросс-аггрегатная валидация.

@iteospace

Жыл бұрын

Согласен, что если перед выполнением какой то операции нужно дернуть другой агрегат или вообще другой контекст?

Спасибо за доклад. Интересная идея как использовать ValueObject из FluentValudator. К сожалению, предлагаемое решение не production ready т.к. оно не позволяет для поля вернуть сразу все ошибки при его валидации. Для полей типа пароля это важно. Лучше было меньше времени посвятить теории множеств, а больше - практичности подаваемого материала

@user-jp8bx3ws6s

10 ай бұрын

Такие библиотеки как ErrorOr и Result позволяют возвращать список ошибок. Вполне можно провалидировать всю сущность и вернуть коллекцию ошибок + даже без использования библиотеки это можно реализовать

зачёт

Спасибо большое за доклад :) Показалось немного странным решением выносить валидацию в AbstractValidator, который скорее всего будет проверяться в каком нибудь пайплайне медиатора только ради того, чтобы потом при создании еще раз провалидировать то же самое при фактическом создании обьекта абсолютно таким же образом) Я пока только новичок, но в чем плохо преимущество использования отдельно FluentValidation с их нормальным синтаксисом, ошибки которого возвращает нормальный список ошибок всей валидации Command и как последний эшелон защиты - уже саму валидацию в доменной модели без вот этих проверок на Result.IsFailure? Ну кроме разве что некоторого количества дубляжа кода, который похож по смыслу и небольшого overhead в поддержке двух мест для валидации (domain model и abstractvalidator)?

Как насчет делать валидацию через паттерн - спецификация? тогда не зависим от внешних либ + читаемость на уровне + можем переиспользовать правила для разных под-типов

а бизнес правила как оформлять в валидацию?

Спасибо за доклад! А почему объекты новые мы создаём через метод Create, а не через конструктор(ы) ?

@vasqainferno583

8 күн бұрын

идея в том, что мы хотим вернуть результат создания Success/Fail, конструктор это не даст сделать, там можно только с исключением упасть

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

так и не понял чем отличается VO от Доменного объекта. у доменного объекта тоже по сути нет идентификации (id) но эта индификация скалдывается из уникального набора данных (например серия и номер паспорта), но все таки это не ид. И если мы получим 2 граждан с одинаковыми серией и номером паспорта значит это один и тот же гражданин. но все таки граждананин, например, не VO (насколько я понимаю)

@timur43378

8 ай бұрын

А чем номер паспорта не уникальный id? Как раз уникальность VO складывается из данных и могут существовать одинаковые VO, а одинаковых энтити не может быть

Приветствую, в заглавии ролика написано Validaton без i

@archdays

Жыл бұрын

Спасибо! Поправим

@DzhigurdaAnton

Жыл бұрын

@@archdays ещё если есть возможность сообщите автору что на 49 странице опечатка. Пункт Инварианты.

про имя студнта в 25 символов "ф1утотй1381" валидное имя ? :)

Спасибо за интересный эфир! А где производить валидацию, если это примитивный тип?