Как правильно валидировать атрибуты сущности?

Question

[alexber220]

Столкнулся с противоречием при реализации сущностей в рамках DDD. С одной стороны мы должны следить за тем чтобы не было возможности получить сущность в невалидном состоянии, а с другой показать в пользовательском интерфейсе какие значения неправильные и почему. Как быть если ошибка в нескольких атрибутах сущности? Дублировать валидацию на клиенте и сервере не хочется. В примерах которые находил кидается исключение сразу при попытке установить неправильное значение атрибута. Что если передавать в конструктор объект в который будут складываться ошибки и в случае появления ошибок в конструкторе объекта они добавляются туда и в самом конце выдаётся исключение? Может я придумываю велосипед и есть уже устоявшееся решение?

Answer 1

[Алексей Скобкин]

А почему вы не можете валидировать данные до передачи в сущность?
Если посмотрите на тот же фреймворк Symfony - компонент валидации вообще не привязан к другим частям системы.

Comments

[alexber220]

Symfony Validator Component мне всем нравится. Есть одно но, в рамках DDD мы должны запретить программисту создать невалидный объект и не дать перевести уже созданный объект в невалидное состояние. Аргумент для такого рода ограничения - это упрощение создания большой сложной системы, чтобы не думать о том что нам могут подсунуть невалидный объект. Возможно я неправильно истолковал DDD или это только всё хорошо в теории и не нужно так заморачиваться, а сделать валидацию на уровне контроллера при создании/изменении объекта и в репозитории перед сохранением? На каком уровне принято валидировать корректность атрибутов объекта?

[Алексей Скобкин]

alexber220: Вы мой первый вопрос проигнорировали, походу. В чём проблема провалидировать данные, а потом создать объект?

[Алексей Скобкин]

alexber220:

На каком уровне принято валидировать корректность атрибутов объекта?

Ну, по логике, и как уже говорили не раз, если делать DDD и для себя и для пользователя, валидация может дублироваться. Есть валидация для пользователя, которая вызывается где-нибудь "из контроллера" (из сервиса, на самом деле, скорее, но так проще будет обозначить), которая нужна чтобы написать, где в форме поля некорректно заполнены. А есть валидация внутри сущности, которая предостерегает от того, что где-то между "контроллером" и конструктором сущности в данных что-то изменилось.

[Алексей Скобкин]

alexber220: https://www.youtube.com/watch?v=rjtbCyacJas
Не факт, что во всём хорош доклад, но в конце в секции вопросов как раз о валидации говорили.

[alexber220]

Алексей Скобкин: огромное спасибо, понял что очень холиварная тема и нужно не парится и делать как удобнее.
Ввсегда валидная сущность неоправданно дорого. Берём Symfony Validator, в сущности пишем правила валидации и валидируем в контроллере и в репозитории при сохранении на случай с выкидыванием исключения в случае ошибок, если программист зевнул.

[alexber220]

Алексей Скобкин: спасибо за очень полезную ссылку на доклад

[Myroslav Berlad]

Советую таке по возможности купиьт / нагуглить книгу : https://leanpub.com/ddd-in-php
Там довольно не плохой подход показан к валидации

[alexber220]

Myroslav Berlad: благодарю за ссылку, читал. Они предлагают валидацию вынести в отдельный объект. Но это же позволит создать невалидную сущность, и, как утверждают отцы DDD, в конечном счёте приведёт к анемичной модели. Где бы посмотреть на реальные примеры применения ddd пусть даже не на php?

Answer 2

[ddd329]

Привет!

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

На самом деле с точки зрения DDD как раз-то противоречий никаких нет. Модель предметной области существует сама по себе, и не делает никаких предположений о своих клиентах, которыми могут быть графические интерфейсы настольных и веб-приложений, и не только...

Как быть если ошибка в нескольких атрибутах сущности?

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

Дублировать валидацию на клиенте и сервере не хочется

Дублировать валидацию можно, если она общеизвестная, например ФИО или email-адрес, зачем перепадать эти значения на сервер, когда в браузере можно выполнить их полноценную валидацию, что повысит время отклика UI. А если логика специфичная, что чаще и бывает, то бизнес-правила должны "лежать" на уровне домена, и не выше.

В общем, мне известно два варианта создания сущностей: используя только публичный конструктор, или используя фабрику(factory). Если я вас правильно понял, то у вас имеется форма с полями для заполнения их значениями, которые являются атрибутами какой-то сущности?
Здесь могут быть два сценария, первый: когда сущность, а точнее АГРЕГАТ, извлекается из репозитория с целью редактирования, то здесь все так, как вы описали выше: неверное значение атрибута - выбрасываем исключение.
И второй сценарий - создание сущности. Нигде нельзя получить доступ к невалидной сущности, созданной с помощью оператора new DomainObject() кроме как фабрики. Поэтому создавайте фабрику, которая позволяет строить вашу сущность, а точнее АГРЕГАТ, по шагам. Для этого примените паттерн проектирования СТРОИТЕЛЬ (Builder). В конце вызовите метод Build(), который и вернет вам валидный АГРЕГАТ.
Что качается промежуточных результатов "строительства", то для их получения используйте паттерн проектирования СНИМОК (Memento), например вот так: var snapshot = domainObjectFactory.GetSnapshot();, где snapshot обычная DTO-ошка, которая содержит значения атрибутов сущностей и списки ошибок, валидность и т.д. Ну а дальше смотрите сами как быть, если вы на клиента передаете ViewModel-s, то используя snapshot создавайте модели представления и дальше их на UI пользователя.