Короче говоря, запрос - это запрос, независимо от того, насколько сложна задача найти его ответ.

но я начал исследовать CQRS и DDD для проекта «зеленого поля», который я собираюсь начать. Я изучил много материала от Уди Дахана, Грега Янга, Марка Нийхофа и других. Они были действительно очень полезны, и я думаю, что у меня есть хорошее понимание концепций. Но у меня все еще есть определенные вопросы о том, как я могу применить их в своей области.

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

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

Очень простое примерное правило может быть:

Для продукта X, ЕСЛИ (Цель покупки = Перепродать и возраст> 25) Добавить 25 $ к базовой цене.

Таким образом, есть 2 типа пользователей, которые используют систему, администраторы, которые определяют продукты, правила и базовые цены; и другие пользователи, которые запрашивают цены на основе сценария, в который они входят через пользовательский интерфейс «что, если».

Моя путаница заключается в следующем: запуск сценария вообще не меняет состояние домена, никакая другая внешняя система или человек не заинтересованы в результате выполнения сценария, кроме самого работающего пользователя - он возвращает результат цены Расчет после запуска применимых правил для данного сценария. Например, пользователь может выбратьПродукт X и запросить цену для данного сценария, например(Цель покупки = перепродать и возраст = 40), Опять же, поскольку эта операция вообще не меняет состояние домена, я думаю, что это запрос. Но в сценарии действует механизм правил для расчета окончательной цены, который, я думаю, можно отнести к категории используемой логики домена. Итак, где эта логика принадлежит? Это запрос, который работает только на модели чтения, или запускает сценарий команду, которую необходимо выполнить в модели домена? Опять же, создается впечатление, что доменный слой - это место для этих правил, но как мне передать результат выполнения сценария пользователю (похоже на запрос, думающий об этом таким образом). Или, может быть, CQRS не является правильным решением для этой конкретной проблемы?

 k3b15 янв. 2011 г., 15:49
+1 за сообщение, что естьCQRS шаблон, который я никогда не слышал раньше.

Ответы на вопрос(2)

планирование 4 здравоохранения). В основном система настроена с использованием доменной модели (сторона записи). Это будет определять правила, продукты и базовые цены в вашем домене. Что выходит из домена? События, изменения состояния, вещи, которые произошли, и почему это произошло. Теперь я использовал эти события в другом ограниченном контексте, в моем случае - в сложной поисковой системе, которая находит свободные места в расписаниях врачей, операционных и дорогостоящего оборудования. Это также может быть маршрут, который вы могли бы использовать, потребляя свой продукт, базовую цену и события, связанные с правилами, и сохраняя их таким образом, чтобы механизм правил, расположенный поверх этих данных, мог обрабатывать запросы пользователей на сценарии так же эффективно, возможно. Скорее всего, вы обнаружите, что модель для хранения изменений (домен) отличается от модели, оптимизированной для запроса тех сценариев «что, если» (механизм правил). Ваш домен, вероятно, будет иметь такие правила, как «нельзя указывать один и тот же продукт дважды» или «это правило никогда не будет соответствовать (возраст <25 && возраст> 25)». Домен касается только допустимых изменений состояния. Это не касается двигателя правил. Вы будете испытывать желание повторно использовать понятия / классы в вашем механизме правил, которые определены в домене. Не поддавайся этому желанию. Вопрос, действительно ли они служат той же цели. Моделирование его дважды для другой цели не является грязным или нарушением СУХОГО.

 KaanK16 янв. 2011 г., 00:46
Спасибо за ваш ответ, Ив. Но я все еще не уверен на 100%. Так у меня есть 3 ограниченных контекста здесь? 1 - модель предметной области (состояние управления на стороне записи), 2 - ограниченный контекст выполнения сценария, 3 - модель чтения для UI - 2 и 3 являются подчиненными 1. И все 3 имеют свой собственный механизм персистентности? Спасибо, Каан.
 Yves Reynhout15 янв. 2011 г., 14:04
Просто чтобы прояснить, нет ничего плохого в использовании подхода, основанного на обработчике запросов, где запросы моделируются как объекты / сообщения (почти как команды и события), а обработчик обрабатывает этот запрос и генерирует ответ на запрос. Это может быть интерфейсом вашего двигателя правил.
 Yves Reynhout16 янв. 2011 г., 11:37
Краткий ответ: да. 3 отдельные модели, которые служат разным целям. Просто прикуси пулю.

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

Короче говоря, запрос - это запрос, независимо от того, насколько сложна задача найти его ответ.

Ваш ответ на вопрос