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

Question

Я ищу проницательность/документы/статьи и т. Д. Возможно ли полное объявление Доменная модель (согласно DDD).

Например:

• Проверка может быть декларативным (Лота ORMs это сделать)
логический поток
• бизнес может быть декларативным: наличие DSL для определения рабочего процесса/конечный автомат/менеджер процесса/DDD Сага (что бы вы там ни называли) на Crud-операциях, через ddd-репозитории, скорее всего,
• логика принятия решения может быть декларативной. I.e: большую часть времени это сводится к простым условностям.
• Выведенные/рассчитанные поля могут быть сделаны декларативно, но это немного сложно, особенно когда это происходит. I.e: вам нужно будет держать график зависимостей от вычисленных полей и т. Д. Тем не менее это можно сделать.

Любые ссылки на людей, которые на самом деле пытались это сделать, или некоторые убедительные аргументы в пользу того, почему этого не может быть сделано?

пс: Пожалуйста, не ответить «Да, это может быть сделано, так как FSM является Тьюрингу с достаточно памяти бла бла»

Answer 1

«Все это гвоздь, если вы держите молоток»

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

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

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

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

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

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

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

Answer 2

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

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

От http://en.wikipedia.org/wiki/Imperative_programming:

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

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

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

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

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