Почему движок правил вместо легко понятного однострочного свойства?

Question

Я новичок с движком правил, так что терпите меня, если этот вопрос очень простой.Во всех руководствах по механизмам правил говорится, что вы можете переместить свою бизнес-логику за пределы кода и обновлять ее БА / конечным пользователям вместо того, чтобы помещать ее в код Java.

У меня есть следующие вопросы

1. Но почему мы не можем написать наш код для чтения значений из файлов свойств и делать то же самое?

2. Кроме того, файлы правил, кажется, имеют синтаксис, который не является просто однострочным, по сравнению с файлами .properties.

3. Помогает ли введение этих правил в механизм правил заставить код / ​​приложение работать без перезагрузки сервера приложений?

   3а.Если это НЕ, то как мы можем этого достичь?

Answer 1

1. Если в логике есть изменения, вы измените файл свойств и снова развернете весь проект.Принимая во внимание, что если вы поддерживаете его с помощью BRMS, вы можете индивидуально изменять и тестировать только BRMS без необходимости повторного развертывания всего проекта.Когда тестирование завершено и вы, наконец, хотите развернуть новое правило на месте, нет необходимости развертывать весь проект в производстве.Если вы выставили свое правило как API с помощью KIE Server, повторное развертывание только сервера KIE подойдет.
2. Можно написать таблицы решений таким образом, чтобы вся логика содержалась в верхних строках.Затем разработчик может заблокировать и скрыть эти верхние строки, а затем передать их BA.Теперь BA не видит никакой логики, но знает, как сохранить файл.Кроме того, не все логики должны быть записаны в виде таблиц решений.
3. Как я уже упоминал выше, каждое правило можно развернуть как отдельный API отдыха, и, следовательно, его можно развернуть независимо от остальных.

В конце я бы сказал, что основная причина, по которой мы используем Redhat BRMS, заключается в том, как они упоминают в своей документации:

1. Гибкость: нет необходимости привлекать разработчиков для запроса на изменение.Сами БА могут изменить логику.
2. Видимость: то, что вы видите (в Excel), это то, что вы получаете.
3. Согласованность: правила оцениваются одинаково каждый раз.

Answer 2

1. Движок правил появляется, когда бизнес-пользователи компании хотят установить определенные правила и управлять приложением, основываясь на результатах выполнения / результатах решений установленных правил.Одним из примеров такой компании может быть юридическая фирма или страховая компания, где юристы устанавливают правила для расчета котировок по страховке, и правила могут изменяться в течение определенного периода времени.Файл свойств - это область разработчика, в которой бизнес-пользователь может не обладать знаниями для внесения изменений.Наличие отдельного механизма правил отслеживает правила и заставляет бизнес-пользователя и разработчика беспрепятственно автоматизировать бизнес, что может быть затруднительно с файлом свойств.
2. Синтаксис файлов правил - это способ преобразования бизнес-правил (словесных) в инструкции по кодированиюкоторые являются исполняемыми.Вот где синтаксис входит в картину.Таким образом, механизм правил обеспечивает абстракцию данных для бизнес-сущностей и их отношений.
3. Интеграция с механизмом правил может быть выполнена с каким-либо брокером или веб-службой или чем-то еще, исходя из этого, серверному приложению нужны правила jar клиента для выполнения вызовапротив.Так что вопрос развертывания и того, как сервер воспринимает изменения / горячие развертывания, если обновлен клиентский файл правил.

Answer 3

За последние несколько дней я немного читал, и я думаю (это ИМХО), что позволяет обновлять бизнес-правила с помощью простых электронных таблиц, что дает Системам правил преимущество над файлами свойств.Я могу сделать файлы свойств максимально настраиваемыми, используя несколько свойств и инструкции для изменения правил в виде комментариев к каждому свойству.

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

ЕслиЛюбой другой (подающий надежды) разработчик, ищущий обоснование необходимости использования Rule Engines, убежден в этом ответе, пожалуйста, оставьте палец вверх!

Answer 4

Правила движков не всегда являются ответом. Однако теоретически они предоставляют преимущество, заключающееся в том, что механизм может выполнять сложную обработку простого выражения правила и возвращать результат. Другими преимуществами являются видимость правил и меньше кода.

Ответы на ваши вопросы.

1. Можно. В простых случаях использование файлов свойств имеет смысл.

2. Правила должны быть достаточно сложными, чтобы охватывать вопросы бизнеса, которые они проверяют. Хороший механизм правил использует синтаксис, который читаем, даже если он сложный.

3. Теоретически сервер правил может работать независимо от сервера приложений. В крупных компаниях это нормально. Сервер правил может разрешить обновления без перезапуска или может быть перезапущен (рифлен, если имеется несколько экземпляров), не затрагивая сервер приложений.