Правила движка - плюсы и минусы

Question

Я проверяю проект, который использует то, что называется Rules Engine . Короче говоря, это способ вывести бизнес-логику из кода приложения.

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

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

ОБНОВЛЕНИЕ - с момента написания этого, сам бог, Мартин Фаулер, писал об использовании механизма правил .

Answer 1

Большинство систем правил, которые я видел, по системному коду рассматриваются как черный ящик. Если бы я строил модель предметной области, я бы хотел, чтобы определенные бизнес-правила были неотъемлемой частью модели предметной области, например, бизнес-правила, которые говорят мне, когда объект имеет недопустимые значения. Это позволяет нескольким системам совместно использовать модель предметной области без дублирования бизнес-логики. Я мог бы заставить каждую систему использовать одну и ту же службу правил для проверки моей доменной модели, но это, похоже, ослабляет мою доменную модель (как было указано в вопросе). Зачем? Поскольку вместо того, чтобы постоянно обеспечивать соблюдение моих бизнес-правил во всех системах, я полагаюсь на системных программистов, чтобы определить, когда следует применять бизнес-правила (вызывая службу правил). Это может не быть проблемой, если модель предметной области приходит к вам полностью заполненной, но может быть проблематичным, если вы имеете дело с пользовательским интерфейсом или системой, которая изменяет значения в модели предметной области в течение своего срока службы.

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

Механизмы правил обычно позволяют изменять правила без перезапуска системы или развертывания нового исполняемого кода (независимо от того, какие обещания вы получаете от поставщика, обязательно проверяйте свои изменения в непроизводственной среде, потому что, даже если правило двигатель безупречен, люди все еще меняют правила). Если вы думаете: «Я могу сделать это, используя базу данных для хранения изменяющихся значений», вы правы. Движок правил - это не волшебная коробка, которая делает что-то новое. Он предназначен для использования в качестве инструмента, который обеспечивает более высокий уровень абстракции, поэтому вы можете меньше сосредоточиться на изобретении колеса. Многие поставщики делают этот шаг дальше, позволяя создавать шаблоны, чтобы бизнес-пользователи могли заполнять пробелы вместо изучения языка правил.

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

Answer 2

Я думаю, что ваши опасения по поводу моделей анемичных доменов верны.

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

Успешное приложение представляет собой приложение дерева решений, состоящее из ~ 10 деревьев по ~ 30 точек ветвления в каждом. У механизма правил есть пользовательский интерфейс, который позволяет деловым людям поддерживать правила.

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

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

Я бы также беспокоился о том, чтобы механизм правил стал узким местом в вашем приложении.

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

Answer 3

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

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

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

Таким образом, файл AWK становится больше похожим на «суп из правил». Эта природа «супа правил» позволяет людям очень пристально сосредоточиться на своей области, не обращая внимания на все остальные правила, которые могут присутствовать в системе.

Например, Фрэнк интересуется заказами на общую сумму более 1000 долларов, поэтому он подключается к системе правил, которая ему интересна. «IF order.total> 1000 THEN email Frank».

Тем временем Салли хочет получить все заказы с западного побережья: "IF order.source == 'WEST_COAST' THEN email Sally".

Итак, вы можете видеть в этом тривиальном надуманном случае, что ордер может удовлетворять обоим правилам, но оба правила не зависят друг от друга. Заказ на 1200 долларов с Западного побережья уведомляет Фрэнка и Салли. Когда Фрэнк перестанет беспокоиться, он просто вытянет свое правило из супа.

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

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

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

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

Answer 4

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

Кроме того, вы не можете недооценивать значение при удалении цикла Recompile-Retest-Redeploy, который может возникнуть в результате простого изменения правила, если правила встроены в код. Часто есть несколько команд, которые участвуют в создании благословения для сборки, и использование движка правил может сделать большую часть этого ненужным.

Answer 5

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

Дело в том, что некоторые программисты не любят многому учиться. Механизмы правил и правила, которые вы в них включаете, вместе с тем, что их реализует, могут быть немного сложными. Хотя хорошая система может легко обрабатывать больные и искаженные сети логики (или часто нелогичные;), она не так проста, как кодирование группы if операторов (независимо от того, что делают некоторые простые движки правил). Механизм правил дает вам инструменты для управления отношениями правил, но вы все равно должны иметь возможность представить все это в своем уме. Иногда это похоже на жизнь в фильме Бразилия . :)

Answer 6

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

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

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

Answer 7

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

Answer 8

"но на самом деле, сколько приложений действительно имеет столько изменений?"

Честно говоря, каждое приложение, над которым я работал, претерпело серьезные изменения в рабочем процессе и / или логике от концепции до задолго до развертывания. Это причина номер один для программирования «обслуживания» ...

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

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

Answer 9

Уже много хороших ответов, но хотелось бы добавить пару вещей:

1. При автоматизации решения любой сложности критическая вещь быстро становится вашей способностью управлять, а не выполнять соответствующую логику. Механизм правил не поможет с этим - вам нужно подумать о возможностях управления правилами, которые есть в системе управления бизнес-правилами. Большинство коммерческих и открытых движков правил превратились в системы управления правилами с репозиториями, отчетами об использовании правил, управлением версиями и т. Д. Репозиторий правил, структурированный в согласованные наборы правил, которые могут быть организованы для принятия бизнес-решений, намного проще в управлении тысячи строк кода или суп из правил.
2. Есть много способов использовать декларативный, основанный на правилах подход. Использование правил для управления пользовательским интерфейсом или для определения процесса может быть очень эффективным. Однако наиболее ценный подход, основанный на правилах, заключается в том, чтобы автоматизировать бизнес-решения и предоставлять их в виде слабо связанных служб принятия решений, которые принимают входные данные, выполняют правила и возвращают ответ - решение. Это относится к услугам, которые отвечают на вопросы по другим услугам, таким как «является ли этот клиент хорошим кредитным риском» или «какую скидку я должен предоставить этому клиенту для этого заказа, или« какова лучшая перекрестная продажа для этого клиента в это время. Эти службы принятия решений могут быть очень эффективно построены с использованием системы управления правилами и позволяют легко интегрировать аналитику с течением времени, чему могут помочь многие решения.

Answer 10

Механизм правил - это победа в настраиваемом приложении, в котором вам не нужно делать пользовательские сборки, если этого можно избежать. Они также хороши для централизации больших баз правил и алгоритмов, таких как Rete , эффективны для быстрого сопоставления с большими наборами правил.