Является ли Drools наиболее эффективным способом отображения бизнес-правил/логики?

Что касается эффективности, у вас не должно возникнуть проблем с Drools. Это звучит как довольно крошечный набор фактов и правил для меня. Движок Rete, на котором он основан, почти наверняка быстрее принимает решения, чем любая куча операторов if-then-else, которые вы сами пишете. И особое преимущество, которое я заметил, заключается в том, что время отклика чрезвычайно предсказуемо.

Очевидно, что все модели фактов и правила различаются, но, например, приложение, которое я сейчас создаю, имеет сотни фактов в рабочей памяти в любое время и более 1000 правил. Он способен принимать решения о входящих запросах примерно за 20 миллисекунд.

Полная структура jBPM не кажется необходимой для того, что вы описываете. Тем не менее, он хорош в том, что он делает. Например, есть графический интерфейс моделирования процессов, если вы хотите разработать рабочие процессы, и Guvnor может быть полезен для авторов нетехнических правил, если техническая группа приложит некоторые усилия для написания DSL и построения таблиц решений.

Для полноты картины основными конкурентами, вероятно, являются FICO Blaze Adviser или IBM ILog JRules. Как правило, когда дело доходит до тестов, они, как правило, немного опережают Drools, но они дороги. По общему признанию, если вы решите платить за контракты на обслуживание JBoss/RedHat, то это не сильно отличается, но если вы рады получить поддержку сообщества в Drools, то это бесплатно!

Единственное, что меня беспокоит по поводу Drools, это то, что для него нет достойного графического интерфейса, который могли бы использовать люди, не связанные с ИТ. Многие продукты заявляют, что предоставляют такой пользовательский интерфейс, но это всегда оказывается не совсем так. Таким образом, вы должны принять тот факт, что ваша команда разработчиков в конечном итоге создаст и протестирует все эти правила на основе таблиц решений или некоторых других форматов.

Помимо этого, Drools — отличный BRE, используемый правительствами, банками и крупными компаниями.

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

• Сколько правил у вас будет? Я бы не рекомендовал какой-либо механизм правил, если правил меньше 20. Это может не оправдать усилий, которые вы потратите на сложность добавления механизма правил только для 7 объектов и 45 действий...
• Потребуются ли вам возможности DSL (Domain Specific Language)? Т.е. будут ли нетехнические люди писать правила? ИМХО, это не очень удобно в Drools по сравнению, например. Оракл ОПА. Но опять же, я еще не видел, чтобы нетехнический человек безопасно возился с системой правил. Помимо изменения значений в таблице решений.
• Как часто ваши правила будут меняться? Если вам нужна централизованная система для управления, версии, упаковки и тестирования ваших правил, то Drools Guvnor — очень функциональный продукт.

jBPM — это не механизм правил, это механизм рабочего процесса. Drools — это механизм правил. Итак, Drools — это то, что вам нужно.

Drools и jBPM — сопутствующие проекты: они очень хорошо интегрируются, если вам нужны рабочие процессы с правилами.

Drools хорош, JBPM немного сложен по сравнению с другими движками BPMN. Я бы посоветовал перейти на Activiti, потому что это немного проще и интегрирует все, что угодно, например, Spring, LDAP и т. Д .; с Активити проще. Также вы можете интегрировать Drools с Activiti. Так что выбирайте Activiti в качестве механизма рабочего процесса и Drools в качестве механизма правил.