Владимир Хориков - Validation and DDD

แชร์
ฝัง
  • เผยแพร่เมื่อ 8 ก.ย. 2024
  • Валидация - довольно большой топик. Существует множество библиотек и подходов к валидации, часто противоречащих друг другу. Сделать выбор в такой ситуации довольно непросто.
    В этом докладе будет показано, как скомбинировать валидацию с практиками Domain-Driven Design, такими как Always-Valid Domain Model и Value Object pattern. Будет также показано, как использовать популярную в .NET библиотеку FluentValidation без нарушения DDD практик.
    Примеры приведены с использованием C# и ASP.NET.

ความคิดเห็น • 24

  • @magicmanam
    @magicmanam 2 ปีที่แล้ว +8

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

  • @eabrega
    @eabrega ปีที่แล้ว +3

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

  • @hakooplayplay3212
    @hakooplayplay3212 ปีที่แล้ว +1

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

  • @NikolayMishin
    @NikolayMishin ปีที่แล้ว +2

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

  • @Eugene.g
    @Eugene.g 2 ปีที่แล้ว +4

    спасибо 👍

  • @VoroninPavel
    @VoroninPavel 2 ปีที่แล้ว +8

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

    • @iteospace
      @iteospace ปีที่แล้ว

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

  • @DevBrothersPro
    @DevBrothersPro 2 ปีที่แล้ว +4

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

    • @user-jp8bx3ws6s
      @user-jp8bx3ws6s ปีที่แล้ว

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

  • @Fikusiklol
    @Fikusiklol ปีที่แล้ว +1

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

  • @igor5379
    @igor5379 10 หลายเดือนก่อน

    зачёт

  • @batazor
    @batazor 4 หลายเดือนก่อน

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

  • @Dimestel
    @Dimestel 9 หลายเดือนก่อน

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

    • @vasqainferno583
      @vasqainferno583 2 หลายเดือนก่อน +1

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

  • @delifeful
    @delifeful ปีที่แล้ว

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

    • @timur43378
      @timur43378 11 หลายเดือนก่อน +1

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

  • @stolentine
    @stolentine ปีที่แล้ว

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

  • @DzhigurdaAnton
    @DzhigurdaAnton ปีที่แล้ว

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

    • @archdays
      @archdays  ปีที่แล้ว +1

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

    • @DzhigurdaAnton
      @DzhigurdaAnton ปีที่แล้ว

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

  • @asbestoable
    @asbestoable ปีที่แล้ว

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

    • @namegorm
      @namegorm 18 วันที่ผ่านมา

      Ты ничего не понял. Код валидаций в доменном слое, первое применение валидаций в Presentation слое.

  • @alexeybeloushko7240
    @alexeybeloushko7240 ปีที่แล้ว

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

  • @KikrAzz
    @KikrAzz 9 หลายเดือนก่อน

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