В DDD это логика приложения проверки или логика домена?

26

Предположим, что мы моделируем форму с использованием DDD; Форма может иметь определенные бизнес-правила, связанные с ней - возможно, вам нужно будет указать доход, если вы не студент, и вам необходимо перечислить своих детей, если вы укажете, что вы состоите в браке. И если вы указали страну, то у нее должна быть действительная страна.

Живет ли этот вид проверки на уровне домена или приложения? Некоторые другие вопросы, которые я рассматривал:

  • Некоторые платформы, такие как Laravel, предоставляют правила проверки, которые могут проверять ввод перед тем, как запрос попадет в контроллер. Это нарушает DDD, если проверка проводится на этом уровне?

  • Для случаев, таких как определение, является ли страна действительной, обычно я просто запрашиваю таблицу базы данных всех стран в мире. Тем не менее, в DDD это, по моему мнению, может быть сделано на уровне домена. Разрешено ли доступу к базе данных доменному слою, или я должен использовать поиск не-SQL, чтобы определить действительную страну?

  • Нужно ли проверять входные данные как на уровне приложения, так и на уровне домена?

Extrakun
источник
6
Ваш вопрос предполагает, что всегда есть одно, правильное место для размещения всего. Нет
Роберт Харви
1
Что говорит @RobertHarvey. Проверка должна всегда проводиться на модели, независимо от какой-либо проверки «приложением» (не является ли часть модели приложением?). Любая проверка в «приложении» должна быть только повторением проверки модели - для повышения отзывчивости пользовательского интерфейса или должна быть связана только с логикой «приложения» (как в: «в этой форме вы можете только ввести». .. ", но я предполагал проверку сущности). Никогда не доверяйте слою «приложение» для проверки домена, это может быть не ваш клиент, отправляющий информацию ...
Marjan Venema

Ответы:

29

Живет ли этот вид проверки на уровне домена или приложения?

Заявка. Волшебный поисковый термин, который вы хотите, это антикоррупционный слой

Как правило, сообщение, полученное вашим приложением, будет некой разновидностью DTO. Ваш антикоррупционный слой обычно создает типы значений, которые распознает домен. Фактическая команда, отправленная в модель предметной области, будет выражена в терминах проверенных типов значений.

Пример: команда DepositMoney, вероятно, будет включать сумму и тип валюты. Представление DTO, вероятно, будет выражать сумму в виде целого числа, а код валюты - в виде строки. Антикоррупционный уровень будет преобразовывать DTO в тип значения Депозита, который будет включать в себя проверенную сумму (которая должна быть неотрицательной) и проверенный код валюты (который должен быть одним из поддерживаемых кодов в домене).

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

Другими словами, бизнес-проверка будет происходить в доменной модели после того, как антикоррупционный уровень проверяет входные данные.

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

VoiceOfUnreason
источник
Почему приложение является ответом? Согласно вашему тексту, формальная проверка может проводиться как в домене или в приложении, так и проверка бизнеса только в домене.
inf3rno
@ inf3rno, потому что вопросы, специально задаваемые о проверке формы, которая не связана с доменом,
августа
1
Этот ответ не имеет смысла. Антикоррупционный уровень DDD - это дополнительный код, который вы пишете для преобразования в / из внешней (другой системы) модели домена и модели домена вашего приложения на основе DDD. Если такой внешней системы нет, антикоррупционный слой отсутствует. Кроме того, проверка бизнес-правил относится к модели домена (и уровню домена), а не к уровню приложения. Что касается DTO, это технический компонент (на уровне приложений), который может существовать или не существовать в приложении DDD. Преобразование между DTO и сущностями / ValueObjects не имеет ничего общего со слоями Антикоррупции.
Рожерио
5

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

Это не означает, что когда ваш домен взаимодействует с людьми (с помощью экранов, форм и т. Д.), Не требуется никакой проверки или помощи. Просто поймите, что это необязательно.

Учтите, что существует два типа бизнес-правил: - правила свойств, которые ограничивают атрибуты объекта, и правила совместной работы, которые ограничивают добавление и удаление совместной работы между объектами.

Бизнес-правила отличаются от логических правил, которые связаны с вашим языком программирования и проверяют, что значения были введены, не являются нулевыми и т. Д.

Примечание: в DDD нет понятия «моделирование» вашей формы.

Арье
источник
0

Будет ли конкретное состояние сделать модель объекта недействительным? Если да, то модель должна помешать сущности перейти в это состояние. Это означает, что модель должна знать, как себя проверить.

Но есть небольшая проблема: проверка модели часто происходит слишком поздно. Часто мы хотим выполнить проверку рано, поэтому пользователю не нужно ждать слишком долго. Вот почему валидация часто вкладывается в логику приложения.

Что касается контекста проверки: нет проблемы с тем, что сущность может запрашивать дополнительные данные. Но это не должно волновать, откуда эти данные. Не имеет значения, исходит ли он от SQL, File или просто жестко запрограммирован. Вот почему существуют хранилища. Домен определяет, какой запрос ему нужен, и позволяет другому человеку позаботиться о реализации.

Euphoric
источник
-2

Уровень домена должен содержать всю логику проверки. Презентация, антикоррупционные уровни или другие зависимые уровни должны отражать это.

Барри Фаассен
источник