Правила использования данных Двигатель - Drools

Question

Я оцениваю Drools как механизм правил для использования в нашем бизнес-приложении.

My use case - приложение для управления заказами.
И следующие правила:
- Если пользовательский тип «СПЕЦИАЛЬНЫЙ» дает дополнительную скидку 5%.
- Если пользователь уже сделал 10+ покупок, дайте дополнительную 3% скидку.
- Если категория продуктов «OLD», дайте Подарочную упаковку пользователю стоимостью 5 долларов.
- Если Категория продукта «NEW», дать подарок Хампера пользователю стоит $ 1
- Если пользователь сделал покупку на сумму свыше $ 1000 в прошлом, доставка Free

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

Так,
- I хотите, чтобы администраторы могли указать это правило из моего пользовательского интерфейса веб-приложения.
- Могу ли я сохранить эти «Правила» в базе данных, а затем работать с ними через Drools - по крайней мере, это позволяет мне «изменять» эти Правила через мой «собственный» интерфейс. Так что это что-то вроде таблицы решений в БД.
- Каков наилучший способ сделать это?

Answer 1

Как правило, я обнаружил, что легче работать на более абстрактном уровне, таком как модель домена, и иметь какое-то программное преобразование от этого к правилам Drools, а не напрямую обращаться к правилам Drools. Таким образом, вы можете сохранить свою модель домена, как вам нравится, и вы можете создавать пользовательские интерфейсы вокруг нее и т. Д. И все еще иметь возможность генерировать правила Drools по требованию. Тогда вызов с этим - это создание программной трансформации из вашей модели в правила Drools, но здесь помогут инструменты шаблонов. Я использовал Groovy templating для этого, и он работал хорошо.

Answer 2

Вы попросили меня ответить на ваш вопрос, учитывая мой ответ Data driven business rules. Мой ответ на этот вопрос заключался в том, что SQL - это плохое решение для выполнить бизнес-правила, хранящиеся в базе данных. Человек, который задал этот вопрос, хотел генерировать выражения SQL из своих хранимых бизнес-правил, и я предостерег от этого, потому что это может привести к проблемам безопасности, тестируемости, производительности и обслуживания.

Я не использовал Drools, но из документации, в которую он входит, входит менеджер по бизнес-правилам Guvnor, который поддерживает использование RDBMS в качестве репозитория для пользовательских правил.

[Drools] Guvnor использует стандарт JCR для хранения таких активов, как правила. Реализация по умолчанию - Apache Jackrabbit, http://jackrabbit.apache.org. Это включает в себя механизм/базу хранения ящиков, который вы можете использовать как есть, или настроить, если необходимо, использовать существующую СУБД.(http://docs.jboss.org/drools/release/5.2.0.Final/drools-guvnor-docs/html/chap-database_configuration.html)

Apache Jackrabbit не РСУБД, это «хранилище контента представляет собой иерархическую содержание магазина с поддержкой структурированных и неструктурированных данных, полнотекстовый поиск, контроль версий, операций, наблюдения и многое другое.» Это похоже на более подходящий репозиторий для Drools.

Но Drools не говорит, что пытается использовать SQL для выполнения этих бизнес-правил. Он имеет отдельный компонент, Drools Expert (Rules Engine) для этого.

Drools Expert - это декларативная, основанная на правилах кодирующая среда. Это позволяет сосредоточиться на том, «что вы хотите делать», а не «как это сделать». (http://www.jboss.org/drools/drools-expert.html)

SQL также декларативный язык программирования, но он предназначен для выполнения реляционных операций над данными таблицы структурированными. Язык для реализации механизма правил имеет разные цели и, возможно, может делать то, что SQL не может (и наоборот).

Поэтому я бы предложил, если вы используете Drools, не стесняйтесь использовать СУБД в качестве репозитория, поскольку они документируют (используйте их JCR-совместимую реализацию репозитория контента, не пытайтесь создавать свои собственные). Затем используйте их Drools Expert как специализированный язык, предназначенный для выполнения правил.

Answer 3

• Там нет смысла UI, что я могу предложить конечным пользователям, чтобы изменить правила.

Из коробки, дяденька обеспечивает web based decision tables (и Excel if you prefer), как вы говорите, что вы хотели бы предоставить. Он предоставляет guided editors для более сложных правил, но ваши правила выглядят очень просто.

• дяденька UI или любой редактор для изменения DRL файлов просто не приемлемо с точки зрения конечного пользователя зрения

Как уже упоминалось, дяденька поддерживает таблицы решений. Если вам не нравится макет веб-приложения Guvnor, вы можете просто embed the Guvnor editors в свое собственное веб-приложение.

• Большинство из этих правил будут работать на часто больших объемов данных, доступных в дб

Размер базы данных не имеет никакого отношения к использованию дяденька. Guvnor предназначен для редактирования правил, а не для оценки времени исполнения. Drools Expert - это механизм правил выполнения. Это быстро. Он может обрабатывать очень большие объемы данных и очень большие объемы правил. Все, что вам нужно сделать, это написать запросы к базе данных, чтобы получить соответствующие куски этих данных в движке правил во время выполнения. Вам нужно это сделать, какое бы решение вы ни пытались реализовать.

На стороне примечания, если то, что вы на самом деле после этого, объясняет, когда правила двигателей являются хорошими (и плохими) решениями проблемы, тогда я бы рекомендовал прочитать раздел Why use a Rule engine? руководства Drools Expert.