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

108

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

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

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

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

BlackTigerX
источник

Ответы:

34

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

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

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

duffymo
источник
1
Разве определение наличия конфликтов не будет вариантом проблемы с остановкой?
TMB
Не знаю, как бы вы это назвали. Что меняется при использовании этого имени? Я ничего не вижу ...
duffymo
@duffymo есть ли примеры "подхода, основанного на большем количестве данных"?
jack.the.ripper 02 фев.15,
Конечно: поместите свои данные в единую таблицу решений и запросите ответы, которые вам нужны. Нет необходимости в движке правил Rete.
duffymo 02
151

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

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

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

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

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

VDev
источник
1
Я думаю, что хороший способ перефразировать ваш урок №2: «Не внедряйте DSL, если вы знаете, что абстракция, содержащаяся в DSL, вероятно, изменится». Разработка и внедрение DSL - это трудоемкий процесс, который вы стремитесь получить в будущем. Если вам нужно воссоздавать DSL каждый цикл, то механизм правил пока не подойдет, пока не произойдет некоторая стабилизация.
ЭТОМ ПОЛЬЗОВАТЕЛЮ НУЖНА ПОМОЩЬ
DSL может быть ресурсоемким, так как интерпретируемые языки программирования тяжелы, но они также могут иметь статическую типизацию и компилироваться при изменении, как и другие скомпилированные языки.
Мэтью Уайтс
19

Я большой поклонник 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

Николае Гузе
источник
18

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

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

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

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

Роберт Гулд
источник
13
Это ваша вина как программиста, а не ошибка пользователя, если он не может использовать вашу систему или если он постоянно достигает с ней непредсказуемых результатов, независимо от того, является ли это BRE или нет. Я бы сказал, что обвинение пользователей в их неспособности использовать ваш код - это абсолютно худший тип программирования, который может иметь проект.
Kizz
Хотя это очень старый пост, но я просто не могу с ним согласиться. Я думаю, что, если возможно, технические специалисты (или поставщик) выполнят настройку для клиентов в процессе внедрения / адаптации, а затем внесут любые серьезные изменения в запрос на обслуживание.
Эрик Синь Чжан
Может быть, кому-то будет полезно прочитать хорошую статью, написанную Мартином Фаулером о DSL: «Позволят ли DSL деловым людям писать правила для программного обеспечения без привлечения программистов?» martinfowler.com/bliki/BusinessReadableDSL.html
Роберт
11

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

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

Smashery
источник
2
проблема в том, что здесь не говорится о реальных стандартных механизмах правил, а только о самодельных механизмах правил, которые являются очень плохой идеей, я говорю о стандартных механизмах правил (Blaze Advisor, ILog, Drools), которые реализуют алгоритм RETE и предоставляют весь экосистема для управления правилами
BlackTigerX
отличная статья, и я думаю, что со стандартным механизмом правил вы можете пойти слишком мягко, иногда делая вещи более сложными,
Дин Хиллер
1
Представьте себе банк с миллионом транзакций в час, потерявшим соединение с механизмом расчета комиссий на 30 минут из-за деполимации разработчиков, представьте, что это был период стабильности, когда у них было много развертываний для исправлений, сколько потерь они понесут, просто остановив одну услугу из биржевые операции, обмен валюты или переводы по SWIFT? Эта статья - одна из худших статей о программировании в целом
2
храгеб, откуда 30 минут простоя? Такие гиганты, как Facebook, постоянно развертывают новое программное обеспечение без простоев. Можно создавать приложения для поддержки обновления узлов в пакетном режиме, вместо того, чтобы останавливать всю систему.
Lauri Harpf
10

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

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

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

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

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

Дин Хиллер
источник
7

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

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

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

DaveParillo
источник
this> _Разработчики программного обеспечения с опытом создания экспертных систем_ <Если вы внимательно прочитаете документацию по слюнявым, вы поймете, что бизнес-правила должны реализовываться разработчиками программного обеспечения, которые хорошо разбираются в алгоритме Rete. Доступ к параметризации правил может быть предоставлен бизнес-пользователям через электронные таблицы или CSV. Тем не менее, правила описываются бизнес-пользователями, но реализуются, как вы говорите, разработчиками программного обеспечения, имеющими опыт работы с экспертными системами. Документы слюни описывают это.
Мэтт Фридман
1

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

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

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

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

Чарли Мартин
источник
0

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

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

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

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

xw
источник