Почему движок правил вместо легко понятного однострочного свойства?
Я новичок с движком правил, так что терпите меня, если этот вопрос очень простой. Во всех руководствах по механизмам правил говорится, что вы можете переместить свою бизнес-логику за пределы кода и обновлять ее с помощью BA / конечных пользователей вместо того, чтобы помещать ее в код Java.
У меня есть следующие вопросы
Но почему мы не можем написать наш код для чтения значений из файлов свойств и делать то же самое?
Кроме того, файлы правил, кажется, имеют синтаксис, который не является просто однострочным, по сравнению с файлами.properties.
Помогает ли помещение этих правил в механизм правил работать с кодом / приложением без перезагрузки сервера приложений?
3a. Если это не так, то как мы можем этого достичь?
5 ответов
Последние несколько дней я читал, и я думаю (это ИМХО), что позволяет обновлять бизнес-правила с помощью простых электронных таблиц, что дает правилам преимущество над файлами свойств. Я могу сделать файлы свойств максимально настраиваемыми, используя несколько свойств и инструкции для изменения правил в виде комментариев к каждому свойству.
Но в сценарии, где бизнес-пользователь может напрямую настроить приложение для применения значений на основе "таблицы решений" в электронной таблице, тогда это решение будет более желательным.
Если какой-либо другой (подающий надежды) разработчик, ищущий обоснование необходимости использования Rule Engines, убедится в этом ответе, пожалуйста, оставьте палец вверх!
- Если в логике есть изменения, вы измените файл свойств и снова развернете весь проект. Принимая во внимание, что если вы поддерживаете его с помощью BRMS, вы можете индивидуально изменять и тестировать только BRMS без необходимости повторного развертывания всего проекта. Когда тестирование завершено и вы, наконец, хотите развернуть новое правило на месте, нет необходимости развертывать весь проект в производстве. Если вы выставили свое правило как API с использованием KIE Server, то можно просто перераспределить только сервер KIE.
- Можно написать таблицы решений таким образом, чтобы вся логика содержалась в верхних строках. Затем разработчик может заблокировать и скрыть эти верхние строки, а затем передать их BA. Теперь BA не видит никакой логики, но знает, как сохранить файл. Кроме того, не все логики должны быть записаны как таблицы решений.
- Как я упоминал выше, можно развернуть каждое правило как отдельный API отдыха, и, следовательно, его можно развернуть независимо от остальных.
В конце я бы сказал, что главная причина, по которой мы используем Redhat BRMS, как они упоминают в своей документации:
- Ловкость: нет необходимости привлекать разработчиков для запроса на изменение. Сами БА могут изменить логику.
- Видимость: то, что вы видите (в Excel), это то, что вы получаете.
- Согласованность: правила оцениваются одинаково каждый раз.
Механизмы правил — это всего лишь алгоритмы для организации множества правил. См . Алгоритм Рете.
В основном все упирается в сложность. Если у вас есть несколько простых правил, конечно, вы можете использовать файл .properties. Но представьте, что некоторые из ваших правил «связаны» — одно правило влияет на какое-то другое свойство, которое запускает какое-то другое правило, которое изменяет другое свойство... вам придется сканировать каждое правило, каждое изменение. Для тысяч правил это заняло бы целую вечность. Следовательно, «движок правил».
Есть много статей о том, почему вы должны или не должны использовать механизм правил. Вот один хороший пример. https://martinfowler.com/bliki/RulesEngine.html
- Движок правил появляется, когда бизнес-пользователи компании хотят установить определенные правила и управлять приложением на основе результатов выполнения / решений по установленным правилам. Одним из примеров такой компании может быть юридическая фирма или страховая компания, в которой юристы устанавливают правила для расчета котировок по страховке, и правила могут изменяться с течением времени. Файл свойств - это область разработчика, в которой бизнес-пользователь может не обладать знаниями для внесения изменений. Наличие отдельного механизма правил отслеживает правила и заставляет бизнес-пользователя и разработчика совместно работать над автоматизацией бизнеса, что может быть затруднительно с файлом свойств.
- Синтаксис файлов правил - это способ преобразования бизнес-правил (словесных) в исполняемые команды кодирования. Вот где синтаксис входит в картину. Таким образом, механизм правил обеспечивает абстракцию данных для бизнес-объектов и их отношений.
- Интеграция с механизмом правил может быть выполнена с каким-либо брокером или веб-службой или чем-то еще, исходя из этого, серверному приложению нужны клиентские jar-коды правил для выполнения вызова. Так что вопрос развертывания и того, как сервер воспринимает изменения / горячие развертывания, если обновлен клиентский файл правил.
Правила движков не всегда являются ответом. Однако теоретически они обеспечивают преимущество, заключающееся в том, что механизм может выполнять сложную обработку простого выражения правила и возвращать результат. Другими преимуществами являются видимость правил и меньше кода.
Ответы на ваши вопросы.
Вы можете. В простых случаях использование файлов свойств имеет смысл.
Правила должны быть достаточно сложными, чтобы охватывать вопросы бизнеса, которые они проверяют. Хороший механизм правил использует синтаксис, который читается, даже если он сложный.
Теоретически сервер правил может работать независимо от сервера приложений. В крупных компаниях это нормально. Сервер правил может разрешить обновления без перезапуска, или он может быть перезапущен (рифлен, если имеется несколько экземпляров), не затрагивая сервер приложений.