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

92

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

Самое лучшее, что у меня есть до сих пор:

  

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

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

    
задан BlackTigerX 04.11.2011 в 21:30
источник
  • О, давай! 43 upvotes, 25 звезд, топ-хит на google, и он закрыт ?! –  Ganesh Krishnan 19.08.2015 в 03:54
  • @GaneshKrishnan: Двенадцать ответов уже достаточно, да? –  Robert Harvey♦ 26.11.2015 в 01:37
  • @RobertHarvey, Итак, что случилось с тем, что у вас больше ответов? Amazon имеет сотни обзоров для многих своих продуктов, и это хорошо. Как вы уверены, что, закрывая вопрос, вы не мешаете еще лучшим ответам на публикацию? –  Dimitre Novatchev 14.11.2016 в 22:55
  • @DimitreNovatchev: Stack Exchange - это не обзоры Amazon. –  Robert Harvey♦ 14.11.2016 в 23:03
  • 12 ответов не захватывают ВСЕ случаи использования анти-шаблонов, когда механизмы бизнес-правил делают хуже, чем хорошо. Модераторы, пожалуйста, передумайте решение закрыть этот вопрос или переместить его в другое место, а не просто закрыть его. –  Vivek Kodira 15.11.2016 в 06:05

11 ответов

29

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

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

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

    
ответ дан duffymo 19.10.2013 в 21:41
  • Не определил бы, есть ли какие-либо конфликты в качестве варианта проблемы с остановкой? –  TMB 11.11.2013 в 23:37
  • Не знаю, как это вы назвали бы. Какие изменения можно использовать, используя это имя? Ничего, что я могу видеть ... –  duffymo 12.11.2013 в 01:21
  • @duffymo любые примеры для «подхода, основанного на данных»? –  jack.the.ripper 02.02.2015 в 14:29
  • Конечно: поместите свои вещи в одну таблицу решений и запросите ответы на нужные вам вопросы. Нет необходимости в механизмах правил Rete. –  duffymo 02.02.2015 в 16:24
124

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

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

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

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

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

ответ дан VDev 07.04.2015 в 06:15
  • Я думаю, что хороший способ перефразировать ваш урок № 2 «не внедрять DSL, если вы знаете, что абстракция, содержащаяся в DSL, может измениться». Проектирование и внедрение DSL - это ресурсоемкий процесс, который вы намерены получить в будущем. Если вам нужно воссоздать DSL каждый цикл, тогда механизм правил не будет подходящим, пока не произойдет некоторая стабилизация. –  THIS USER NEEDS HELP 02.04.2018 в 01:42
15

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

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

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

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

Более подробную информацию по этой теме можно найти в сообщении, которое я написал: Ссылка

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

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

Николай     

ответ дан Nicolae Guse 22.01.2012 в 10:03
  • Хорошая статья! Мой прецедент - это хранилище данных, которое находится в зачаточном состоянии. Так что это было очень полезно! –  MacGyver 02.09.2013 в 23:50
13

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

  

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

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

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

    
ответ дан Robert Gould 22.04.2009 в 02:00
  • Это ваша ошибка как программист, а не ошибка пользователя, если он не может использовать вашу систему или если (а) он постоянно достигает непредсказуемых результатов, будь то BRE или нет. Я бы сказал, что обвинять пользователей в их неспособности использовать ваш код - это абсолютно худший тип программирования, который может иметь проект. –  Kizz 23.03.2013 в 14:29
10

Я думал, что статья Алекса Пападимулиса была довольно проницательной: Ссылка

Это не полный, но у него есть хорошие моменты.

    
ответ дан Smashery 22.04.2009 в 01:56
  • заключается в том, что она не говорит о реальных механизмах стандартных правил, а только о домашних, которые являются очень плохими идеями, я говорю о механизмах стандартных правил (Blaze Advisor, ILog, Drools), которые реализуют алгоритм RETE и обеспечить целую экосистему для управления правилами –  BlackTigerX 18.06.2009 в 21:59
  • потрясающая статья, и я думаю, что вы можете пойти в тупик со стандартным движком правил, иногда делая вещи более сложными –  Dean Hiller 04.11.2011 в 18:46
  • Представьте себе, что банк с миллионными транзакциями в час потерял связь с механизмом правил расчета платежей за 30 минут, потому что разработчики деполируют, представьте себе, что это был период стабильности, когда у них много развертываний для исправлений, сколько потерь у них будет, просто остановив одна услуга биржевой торговли, иностранной валюты или переводов SWIFT? Эта статья является одной из худших статей о программировании в целом –  18.06.2015 в 04:23
  • hragheb, откуда исходит 30 минут простоя? Гиганты вроде Facebook постоянно развертывают новое программное обеспечение без простоя. Приложения могут быть созданы для поддержки обновления узлов партиями, а не для удаления всей системы. –  Lauri Harpf 03.07.2015 в 13:00
8

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

Ссылка

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

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

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

    
ответ дан Dean Hiller 22.08.2016 в 16:48
6

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

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

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

    
ответ дан DaveParillo 30.09.2009 в 17:37
  • this> _Software разработчики с опытом создания экспертных систем_ <Если вы внимательно прочитаете документы drools, вы поймете, что бизнес-правила должны быть реализованы разработчиками программного обеспечения, которые имеют сильное понимание алгоритма Rete. Доступ к параметризации правил может быть предоставлен бизнес-пользователям через электронные таблицы или CSV. Правила, тем не менее, описаны бизнес-пользователями, но реализованы, как вы говорите, разработчиками программного обеспечения с опытом работы в экспертных системах. Об этом говорится в drools docs. Проблема –  Matt Friedman 24.02.2018 в 01:29
1

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

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

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

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

    
ответ дан Charlie Martin 22.04.2009 в 01:57
0

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

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

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

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

ответ дан x w 21.05.2013 в 16:31
-1

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

Вы можете проверить это здесь - & gt; Ссылка

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

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

    
ответ дан Srikar Doddi 22.04.2009 в 02:32
  • У меня есть много причин использовать Rules Engines, я хочу, чтобы сценарии, когда они не подходят –  BlackTigerX 23.04.2009 в 20:21
  • одна вещь, которую я могу сказать вам прямо на летучей мыши из моего опыта, не использует механизмы правил, если вы не ожидаете, что они будут меняться ежедневно, как новые правила на рынке форекс, фондовые рынки, система котировок автомобилей. Четко объясняйте свои требования, поэтому вы знаете, нужно ли создавать механизм документооборота или механизм правил. Я иногда видел, что некоторые правила проскальзывают. Вы должны заранее знать все сценарии. –  Srikar Doddi 24.04.2009 в 05:23
  • Самая распространенная ложь, которую я слышу о Rule Engines, такой как Drool: Бизнес-пользователи могут изменять свои собственные правила. В самом деле? Попробуйте предоставить drl-файл вашему следующему бизнес-пользователю. –  Jasper 13.08.2013 в 09:33
  • вы можете обновить ссылку. это не работает –  Sandeep 06.07.2017 в 09:32
  • Ссылка отсутствует –  freedev 06.09.2017 в 13:41