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

У меня есть довольно приличный список преимуществ использования движка правил, а также некоторые причины их использования; мне нужен список причин, по которым вы НЕ должны использовать движок правил.

Лучшее, что у меня есть, это следующее:

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

Есть ли другие веские причины, почему вы не должны их использовать?

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

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

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

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

1. В прошлом проекте я заметил, что файлы правил (в проекте использовались Drools) содержали много Java-кода, включая циклы, функции и т. Д. По сути, это были файлы Java, маскирующиеся под файл правил. Когда я спросил архитектора, почему он обосновал этот проект, мне ответили, что «Правила никогда не предназначались для соблюдения бизнес-пользователями».

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

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

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

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

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

Тем не менее, у такого подхода есть пределы:

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

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

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

Ура,

Nicolae

Я заметил, что «палка о двух концах»:

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

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

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

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

Он не исчерпывающий, но у него есть несколько хороших моментов.

ОТЛИЧНАЯ статья о том, когда не использовать движок правил ... (а также когда его использовать) ....

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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