Возможна ли декларативная модель домена (DDD)?

"Все - гвоздь, если держать молоток"

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

Проверка данных - это хорошая вещь, которую нужно делать декларативно. У вас есть DTO, вы добавляете атрибуты, все понятно и читается.

Бизнес-поток, сделанный декларативно ... Мне это напоминает большой провал Windows Workflow Foundation. Кто-нибудь вообще этим пользуется? В чем преимущество декларативного создания компонентов, ориентированных на поведение? Императивный путь, кажется, подходит для этого. Логика принятия решения ... может быть. Но опять же - почему?

«Производные / вычисляемые поля могут быть выполнены декларативно, но это немного сложно». Почему вы хотите делать сложные вещи, когда есть способ достичь того же результата с помощью простых вещей?

Так почему? Вам нужно изменить поведение приложения во время выполнения, отредактировав какой-либо файл конфигурации? Хорошо, дерзай.

У вас есть общий домен, который будет использоваться многими клиентами, и вам нужна некоторая реконфигурация, чтобы он соответствовал им? Хорошо, но вам нужно четко различать неизменное ядро ​​вашего домена и различные вещи. Не пытайтесь сделать все настраиваемым - вы получите синдром внутренней платформы.

Считаете ли вы, что можете создать декларативный язык, который ваш клиент мог бы использовать для изменения своего домена без необходимости в программисте? Нет. Вы проиграете. Я знаю язык, который должен был быть таким. Простой декларативный язык, который обычные бухгалтеры использовали бы для исследования своих данных. Это называется SQL: D

Я полностью согласен с замечанием Бартломея Шипелова. Тем не менее, я постараюсь ответить на ваш вопрос.

Декларативный язык всегда зависит от императивного языка, чтобы он работал. Возьмем, к примеру, такую ​​простую вещь, как арифметика. Когда мы запрашиваем результат 1+1, нам сначала нужно знать, как следует понимать 1 и как в этом контексте может быть вычислен оператор +, прежде чем можно будет интерпретировать оператор в целом. Это один из способов преодоления сложности; вам не нужно знать, как выполняется операция «плюс», чтобы использовать ее.

Из http://en.wikipedia.org/wiki/Imperative_programming:

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

То же самое применимо в любом домене. Если вы попросите бортпроводника reschedule ваш flight, она знает, что такое рейс и пассажир и как reschedule один. Поэтому создание полностью декларативной модели предметной области планирования полетов без описания того, как работает планирование, невозможно. Поскольку все модели предметной области содержат операции / поведение, поэтому в равной степени невозможно создать модель предметной области на декларативном языке, если только ваша проблемная область не является уникальной, например, когда у вас есть три летные компании, которые работают аналогичным образом.

Вернемся к тому, почему ... вы сказали:

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

Декларативное программирование не всегда проще императивного. Большую часть времени люди склонны думать о результатах, но иногда результаты настолько разнообразны, что (намного) проще думать поэтапно. Это причина, по которой эти разные стили существуют и продолжают существовать в первую очередь. Основное различие между кодировщиком и не кодировщиком заключается не в том, что не кодировщик склонен думать в терминах результатов, а не процессов, а в том, что не кодировщик просто не хочет, чтобы его беспокоили работа компьютера. Некодер хочет сосредоточиться на проблеме. В зависимости от домена, некодирующему лучше всего может помочь императивный DSL вместо декларативного DSL.