Когда вы НЕ используете механизм правил?

Ответ 1

Я очень нервничаю, когда вижу людей, использующих очень большие наборы правил (например, порядка тысяч правил в одном наборе правил). Это часто происходит, когда движок правил синглтон сидит в центре предприятия в надежде, что соблюдение правил DRY сделает их доступными для многих приложений которые требуют их. Я бы бросил вызов любому, чтобы сказать мне, что механизм правил Rete с этим множеством правил хорошо понимается. Я не знаю никаких инструментов, которые могут проверять, чтобы конфликты не существовали.

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

Я предпочитаю более простой, более основанный на данных подход, когда это возможно.

Ответ 2

Я приведу 2 примера из личного опыта, когда использование механизма правил было плохой идеей, возможно, это поможет: -

• В прошлом проекте я заметил, что файлы правил (проект использовал Drools) содержал много java-кода, включая циклы, функции и т.д. Они были по существу java файлами, маскирующимися как файлы правил. Когда я спросил архитектора о его рассуждениях о дизайне, мне сказали, что "Правила никогда не должны поддерживаться бизнес-пользователями".

Урок: они называются "Бизнес-правилами" по какой-либо причине, не используйте правила, когда вы не можете создать систему, которая может быть легко поддержана/понята бизнес-пользователями.

2. Другой случай; В проекте использовались правила, поскольку требования были плохо определены/поняты и часто менялись. Решение команды разработчиков заключалось в том, чтобы широко использовать правила, чтобы избежать частого развертывания кода.

Урок. Требования часто меняются во время первоначальных изменений выпуска и не требуют использования правил. Используйте правила, когда ваш бизнес часто меняется (а не требования). Например: - Программное обеспечение, которое ваши налоги будут меняться каждый год, поскольку законы о налогообложении меняются, а использование правил - отличная идея. Версия 1.0 веб-приложения будет часто меняться, поскольку пользователи определяют новые требования, но со временем стабилизируются. Не используйте правила в качестве альтернативы развертыванию кода.

Ответ 3

Я большой поклонник двигателей бизнес-правил, так как это может помочь вам сделать вашу жизнь намного проще программистом. Один из первых опытов, которые я имел при работе над проектом Data Warehouse, заключался в том, чтобы найти Хранимые процедуры, содержащие сложные структуры CASE, растянувшиеся по целым страницам. Это был кошмар для отладки, поскольку было очень сложно понять логику, применяемую в таких длинных структурах CASE, и определить, есть ли у вас перекрытие между правилом на странице 1 кода и другое со страницы 5. В целом, мы имели более 300 таких правил, встроенных в код.

Когда мы получили новое требование к разработке, для чего-то, называемого Accounting Destination, в котором участвовало более 3000 правил, я знал, что что-то должно измениться. В то время я работал над прототипом, который позже стал родителем того, что теперь является механизмом Custom Business Rule, способным обрабатывать все стандартные SQL-операторы. Первоначально мы использовали Excel в качестве средства разработки, а позже мы создали приложение ASP.net, которое позволит бизнес-пользователям определять свои бизнес-правила без необходимости писать код. Теперь система работает нормально, с очень небольшим количеством ошибок и содержит более 7000 правил для расчета этого пункта назначения. Я не думаю, что такой сценарий был бы возможен благодаря простому кодированию. И пользователи очень рады, что они могут определять свои собственные правила, не становясь их узким местом.

Тем не менее, существуют ограничения для такого подхода:

• Вам нужно иметь способных бизнес-пользователей, которые отлично понимают бизнес компании.
• Существует значительная рабочая нагрузка на поиск всей системы (в наш случай a Data Warehouse), чтобы определить все жестко закодированные условия, которые имеют смысл перевести на правила, которые должны обрабатываться механизм бизнес-правил. Мы также должны были заботиться о том, чтобы эти начальные шаблоны должны быть полностью понятны бизнес-пользователям.
• Вам необходимо иметь приложение, используемое для создания правил, в котором реализованы алгоритмы для обнаружения перекрывающихся бизнес-правил. В противном случае у вас будет большой беспорядок, когда никто не поймет, какие результаты они получат. Когда у вас есть ошибка в общем компоненте, таком как механизм пользовательских бизнес-правил, его может быть очень сложно отлаживать и включать в себя обширные тесты, чтобы убедиться, что все, что работало до этого, также работает сейчас.

Более подробную информацию по этой теме можно найти в сообщении, которое я написал: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

В целом, самым большим преимуществом использования Business Rule Engines является то, что он позволяет пользователям возвращать контроль над определениями и авторингом Business Rule, без необходимости обращаться в ИТ-отдел каждый раз, когда им нужно что-то изменить. Это также снижает нагрузку на команды разработчиков ИТ, которые теперь могут сосредоточиться на создании материалов с большей добавленной стоимостью.

Приветствия,

Николай

Ответ 4

Один поэт, который я заметил как "обоюдоострый меч":

размещение логики в руках нетехнического персонала

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

Таким образом, вы должны серьезно относиться к своей пользовательской базе.

Ответ 5

Я подумал, что статья Алексея Пападимулиса была довольно проницательной: http://thedailywtf.com/articles/soft_coding.aspx

Это не всеобъемлющий, но у него есть хорошие моменты.

Ответ 6

ВЕЛИКАЯ статья о том, когда не использовать правила Engine... (а также когда их использовать)....

http://www.jessrules.com/guidelines.shtml

Другой вариант - если у вас есть линейный набор правил, который применяется только один раз в любом порядке для получения результата, это создать интерфейс groovy и разработчики будут писать и развернуть эти новые правила. Преимущество заключается в том, что оно злобно быстро, потому что обычно вы должны проходить сеанс hibernate или сеанс jdbc, а также любые параметры, чтобы у вас был доступ ко всем вашим данным приложений, но эффективным образом. В списке фактов может быть много циклов/совпадений, которые действительно могут замедлить работу системы. Это еще один способ избежать механизма правил и динамического развертывания (да, наши правила groovy были развернуты в базе данных, и у нас не было рекурсии... она либо соответствовала правилу, либо не делала этого). Это еще один вариант..... о, и еще одно преимущество - не обучение синтаксису правил для входящих разработчиков. Они должны изучить некоторые groovy, но это очень близко к java, поэтому кривая обучения намного лучше.

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

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

Ответ 7

По моему опыту, двигатели правил работают лучше всего, когда верно следующее:

• Четкая доктрина для вашей проблемной области.
• Высококачественные (предпочтительно автоматизированные) данные, которые помогут вам управлять большинством ваших входов.
• Доступ к экспертам по тематике
• Разработчики программного обеспечения с опытом создания экспертных систем

Если какой-либо из этих четырех признаков отсутствует, вы все равно можете найти механизм правил для вас, но каждый раз, когда я пробовал его с 1 отсутствием, я столкнулся с трудностями.

Ответ 8

Это, конечно, хорошее начало. Другое дело, что с механизмами правил - это то, что некоторые вещи хорошо понятны, детерминированы и прямолинейны. Удержание заработной платы является (или может быть) таким. Вы можете выразить это как правила, которые будут разрешены механизмом правил, но вы можете выразить те же правила, что и довольно простая таблица значений.

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

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

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

Ответ 9

Я бы настоятельно рекомендовал двигатели бизнес-правил, такие как Drools как открытый источник или Коммерческие правила двигателя, такие как LiveRules.

• Когда у вас много бизнес-политик, которые нестабильны по своей природе, очень сложно поддерживать эту часть основного технологического кода.
• Механизм правил обеспечивает большую гибкость структуры и легко изменяет и развертывает.
• Двигатели правил не должны использоваться повсеместно, но их нужно использовать, когда у вас много политик, где изменения неизбежны на регулярной основе.

Ответ 10

Я не очень понимаю некоторые моменты, например:
a) деловые люди должны понимать бизнес очень хорошо, или; б) несогласие с деловыми людьми не обязательно должно знать правило.

Для меня, как людей, которые просто касаются BRE, преимущество BRE называется так, чтобы система адаптировалась к изменениям в бизнесе, поэтому она была ориентирована на адаптацию изменений.
Имеет ли значение, если правило, установленное в момент времени x, отличается от правила, установленного в момент времени y из-за:
а) деловые люди не понимают бизнес, или; б) деловые люди не понимают правил?

Ответ 11

Я писал об этом некоторое время назад.

Вы можете проверить это здесь → http://www.codetoglory.com/?p=21

Вы действительно должны использовать его, когда у вас есть динамические правила, которые постоянно меняются, как страховые, торговые и валютные домены.

Надеюсь, что моя статья в блоге может дать вам хороший обзор.