Правила Двигатель - за и против

Question

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

Эта концепция для меня совершенно новая, и я довольно скептически отношусь к ней. После того, как в течение последних нескольких лет люди говорят о Anemic Domain Models, я задаю вопрос о подходе к правилам. Для меня они кажутся отличным способом сгладить модель домена. Например, я говорю, что я делаю java webapp, взаимодействую с механизмом правил. Затем я решил, что хочу иметь приложение для Android, основанное на том же домене. Если я не хочу, чтобы приложение Android взаимодействовало с механизмом правил, мне придется пропустить любую бизнес-логику, которая уже была написана.

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

ОБНОВЛЕНИЕ - после написания этого, сам Бог, Мартин Фаулер, имеет blogged about using a Rules engine.

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

«но действительно, сколько приложений действительно имеет много изменений?»

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

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

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

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

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

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

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

Answer 10

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

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

Answer 11

Я вижу правила, процессы и двигатели данных (базы данных a.k.a.) как по существу похожие. Но по какой-то причине мы никогда не говорим, что blackboxing подсистема сохранения является плохим.

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

Answer 12

Самая большая сложность из моего опыта в Rule двигателей является то, что:

1. от объектно-ориентированного POV это реальная боль, чтобы реорганизовать и правила испытаний написаны на декларативном языке, когда вы рефакторинга кода, который влияет на их.
2. Часто мы всегда должны думать о порядке выполнения правил, который превращается в беспорядок, когда их много.
3. Некоторые незначительные изменения могут вызывать неправильное поведение правил, приводящих к ошибкам производства. На практике не всегда возможно охватывать все случаи с проверками спереди.
4. Правила, изменяющие объекты, используемые в других, также увеличивают сложность, заставляя разработчиков разбивать их на этапы.