Проверка объекта DDD

Question

Мы строим портал недвижимости. У нас есть Сервисы, Mappers и Entites. На этапе мы разрешаем пользователям либо

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

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

• для подтверждения того, что пользователь предоставил файл
• типа файла действителен
• и размер файла находится в пределах допустимые пределы.

После этого он должен передать файл в контроллер или службу.

Теперь отложенные задачи

• Обработать файл и извлечь содержимое
• проверить содержимое
• Если подтверждено, сохранить свойства или выводится сообщение об ошибке.

Итак, какая часть (-ы) отвечает за вышеуказанные задачи?

Я думаю, что контроллер должен выполнить начальную обработку файла и передать данные службе. Это означает, что мы создадим/извлечем объект формы в контроллере и проверим форму внутри контроллера.

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

1. Служба проверит данные и создаст объекты, они сохранят их.
2. Или служба создаст объект с предоставленными данными, а затем вызовет функцию проверки сущности.
3. Или служба попытается создать объект с предоставленными данными (передавать данные в конструктор объекта), а также, если данные верны, будет создан объект или будет генерировать ошибку и т.д.

возможные вопросы, которые я могу думать о вышеуказанных подходах

• Если служба проверки достоверности данных, это означает, что служба будет знать внутреннюю структуру объекта, так что, если по дороге нам необходимо обновить структуру лица , мы также должны обновить сервис. Что представит какую-то зависимость.
• Во втором подходе я не думаю, что объект должен быть создан на первом месте, если он недействителен.
• В третьем подходе мы создаем функциональность внутри конструктора сущности, что делает сущность зависимой от данных.Поэтому, когда нам нужно получить сущность от постоянной, нам необходимо предоставить некоторые данные о заглушке.

Или я передумал ???

Answer 1

Это зависит от того, какие ограничения вы проверяете.

1.parameter проверки как notEmpty имя свойства или максимальная длина и т.д.

В этом случае вы могли бы извлечь логику проверки на объект Validator. Это полезно, когда у вас есть несколько форм создания свойств (веб-форма, загрузка файлов), валидатор может вызываться несколькими «клиентом», но логика проверки сохраняется в одном объекте.

2.business правило проверка.

Я предпочитаю использовать модели предметной области, вы можете посмотреть на пример PhoneNumber в этом presentation

Answer 2

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

В Содержание, что контроллер посылает услуг, представляет собой график объектов/структуру/простая строка в простейшем случае, но никогда не собрание субъектов предпринимательства.

Если служба проверки достоверности данных, это означает, что служба будет знать внутреннюю структуру объекта

Что именно служба Validating?

Service является проверка данных означает, что служба обеспечивает инвариант каждой структуры/объекта, который он получает.

Например, если F(T) является метод обслуживания и T является структура со свойствами { A, B, C }, что представляет собой треугольник с тремя ребрами, то служба должна обеспечить инварианты (длина каждого участка больше, то нулевой и сумма длин любых двух сторон должна быть больше длины третьей стороны) этой структуры после того, как эта структура была десериализована.

Эта проверка должна быть выполнена, поскольку десериализатор не использует конструкторы для обеспечения инвариантов во время десериализации.

Когда эти проверки выполнены, все объекты, переданные в Сервис действительны и могут быть свободно использованы в бизнес-слое напрямую или преобразованы в объекты (например, объекты), известные бизнес-уровню.

Если по дороге нам необходимо обновить структуру сущности, мы также должны обновить ее. Что представит какую-то зависимость.

Эта зависимость неизбежна. Начиная с Объекты переноса и Объекты Entity Объекты разделены, всегда существует mapper, который знает, как их преобразовать.

Служба проверит данные и создаст объекты, они сохранят их.

Я бы поехал с этим. Служба проверяет данные, преобразует их в объекты бизнес-уровня, вызывает функции бизнес-уровня, сохраняет изменения.