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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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