Правила движка - плюсы и минусы
https://stackoverflow.com/questions/250403
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я проверяю проект, в котором используется так называемый механизм правил . Короче говоря, это способ вывести бизнес-логику из кода приложения.
Эта концепция совершенно новая для меня, и я довольно скептически к ней отношусь. Услышав, что люди говорят о моделях анемичных доменов в течение последних нескольких лет, я задаю вопрос Подход двигателя правил. Мне они кажутся отличным способом ослабить модель предметной области. Например, скажите, что я делаю Java-приложение, взаимодействующее с движком правил. Затем я решаю, что хочу иметь приложение для Android на основе того же домена. Если я не хочу, чтобы приложение Android также взаимодействовало с движком правил, мне придется пропустить любую уже написанную бизнес-логику.
Поскольку у меня пока нет с ними опыта, просто любопытство, мне было интересно услышать о плюсах и минусах использования механизма правил? Единственный профессионал, о котором я могу подумать, это то, что вам не нужно перестраивать все приложение целиком, чтобы просто изменить какое-то бизнес-правило (но на самом деле, сколько приложений действительно имеет столько изменений?). Но использование механизма правил для решения этой проблемы для меня звучит как наложение бинта на рану дробовика.
ОБНОВЛЕНИЕ - с момента написания этой статьи сам бог Мартин Фаулер писал об использовании механизма правил .
Решение
Большинство систем правил, которые я видел, рассматриваются как черный ящик системным кодом. Если бы я строил модель предметной области, я бы хотел, чтобы определенные бизнес-правила были неотъемлемой частью модели предметной области, например, бизнес-правила, которые говорят мне, когда объект имеет недопустимые значения. Это позволяет нескольким системам совместно использовать модель предметной области без дублирования бизнес-логики. Я мог бы заставить каждую систему использовать одну и ту же службу правил для проверки моей доменной модели, но это, похоже, ослабляет мою доменную модель (как было указано в вопросе). Зачем? Поскольку вместо того, чтобы постоянно обеспечивать соблюдение моих бизнес-правил во всех системах, я полагаюсь на системных программистов, чтобы определить, когда следует применять бизнес-правила (вызывая службу правил). Это может не быть проблемой, если модель предметной области приходит к вам полностью заполненной, но может быть проблематичным, если вы имеете дело с пользовательским интерфейсом или системой, которая изменяет значения в модели предметной области в течение своего срока службы.
Существует еще один класс бизнес-правил: принятие решений. Например, страховой компании может потребоваться классифицировать риск андеррайтинга заявителя и получить премию. Вы могли бы поместить эти типы бизнес-правил в модель вашего домена, но централизованное решение для подобных сценариев обычно желательно и, фактически, вполне вписывается в сервис-ориентированную архитектуру. Это ставит вопрос о том, почему движок правил, а не системный код. Место, где механизм правил может быть лучшим выбором, - это когда бизнес-правила, ответственные за принятие решения, со временем меняются (как указывали некоторые другие ответы).
Механизмы правил обычно позволяют изменять правила без перезапуска системы или развертывания нового исполняемого кода (независимо от того, какие обещания вы получаете от поставщика, обязательно проверяйте свои изменения в непроизводственной среде, потому что, даже если правило двигатель безупречен, люди все еще меняют правила). Если вы думаете, «я могу сделать это, используя базу данных для хранения значений, которые меняются», вы правы. Движок правил - это не волшебная коробка, которая делает что-то новое. Он предназначен для использования в качестве инструмента, который обеспечивает более высокий уровень абстракции, поэтому вы можете меньше сосредоточиться на изобретении колеса. Многие поставщики делают этот шаг дальше, позволяя создавать шаблоны, чтобы бизнес-пользователи могли заполнять пробелы вместо изучения языка правил.
Одно прощальное предостережение в отношении шаблонов: шаблоны не могут занимать меньше времени, чем написание правила без шаблона, потому что шаблон должен, как минимум, описывать правило. Планируйте более высокую начальную стоимость (так же, как если бы вы строили систему, в которой для хранения значений, которые изменяются, и записи правил непосредственно в системном коде, использовалась база данных), рентабельность инвестиций заключается в том, что вы экономите на будущем обслуживании системного кода. .
Другие советы
Я думаю, что ваши опасения по поводу моделей анемичных доменов верны.
Я видел два приложения известного коммерческого движка правил Rete, работающего на производстве, где я работаю. Я бы посчитал один успехом, а другой неудачей.
Успешное приложение представляет собой приложение дерева решений, состоящее из ~ 10 деревьев по ~ 30 точек ветвления в каждом. Механизм правил имеет пользовательский интерфейс, который позволяет деловым людям поддерживать правила.
Менее успешное приложение имеет ~ 3000 правил, помещенных в базу данных правил. Никто не знает, существуют ли противоречащие друг другу правила при добавлении нового. Существует мало понимания алгоритма Rete, и опыт работы с продуктом покинул фирму, поэтому он стал черным ящиком, который неприкосновенен и не подлежит восстановлению. Изменения правил по-прежнему зависят от цикла развертывания - при изменении правил необходимо выполнить полный регрессионный тест. Память тоже была проблемой.
Я бы пошёл слегка. Когда набор правил скромен по размеру, легко понять изменения, как, например, упрощенный пример электронной почты, приведенный выше. Как только количество правил возрастет до сотен, я думаю, у вас могут возникнуть проблемы.
Я бы также беспокоился о том, чтобы механизм правил стал узким местом в вашем приложении.
Я не вижу ничего плохого в использовании объектов в качестве способа разбиения, который управляет пространством движка. Встраивание поведения в объекты, которые относятся к частному механизму правил, мне кажется вполне приемлемым. Проблемы поразят вас, когда движок правил требует, чтобы состояние, которое не является частью его объекта, корректно срабатывало. Но это еще один пример сложности дизайна.
В некоторых случаях модули правил могут иметь большую ценность.
Во-первых, многие механизмы правил работают более декларативно. Очень грубым примером будет AWK, где вы можете назначить регулярные выражения для блоков кода. Когда регулярное выражение видит файловый сканер, блок кода выполняется.
Вы можете видеть, что в этом случае, если, скажем, у вас был большой файл AWK и вы хотели добавить еще одно " правило " ;, вы можете легко перейти к нижней части файла, добавить регулярное выражение и логику, и покончим с этим. В частности, для многих приложений вас не особенно беспокоит то, что делают другие правила, и эти правила на самом деле не взаимодействуют друг с другом.
Таким образом, файл AWK становится больше похожим на «суп из правил». Это «суп из правил» природа позволяет людям сосредоточиться на своей области, не заботясь обо всех других правилах, которые могут присутствовать в системе.
Например, Фрэнк интересуется заказами на общую сумму более 1000 долларов, поэтому он подключается к системе правил, которая ему интересна. " IF order.total > 1000 ТОЛЬКО по электронной почте Фрэнк.
Тем временем Салли хочет получить все заказы с западного побережья: " IF order.source == 'WEST_COAST' THEN отправьте электронное письмо Салли ".
Итак, вы можете видеть в этом тривиальном надуманном случае, что порядок может удовлетворять обоим правилам, но оба правила независимы друг от друга. Заказ на 1200 долларов с Западного побережья уведомляет Фрэнка и Салли. Когда Фрэнк перестанет беспокоиться, он просто вытянет свое правило из супа.
Во многих ситуациях эта гибкость может быть очень мощной. Как и в этом случае, он может быть представлен конечным пользователям для простых правил. Использование выражений высокого уровня и, возможно, легких сценариев.
Теперь ясно, что в сложной системе существуют всевозможные взаимосвязи, и именно поэтому вся система не «выполнена с правилами». Кто-то где-то будет отвечать за то, чтобы правила не выходили из-под контроля. Но это не обязательно уменьшает ценность, которую может обеспечить такая система.
Имейте в виду, что это даже не относится к таким вещам, как экспертные системы, где правила запускаются на данных, которые могут быть созданы правилами, но к более простой системе правил.
В любом случае, я надеюсь, что этот пример показывает, как система правил может помочь дополнить более крупное приложение.
Самый большой плюс, который я видел для механизмов правил, заключается в том, что он позволяет владельцам бизнес-правил реализовывать бизнес-правила вместо того, чтобы возлагать ответственность на программистов. Даже если у вас есть гибкий процесс, в котором вы постоянно получаете обратную связь от заинтересованных сторон и проходите быстрые итерации, он все равно не достигнет уровня эффективности, которого можно добиться, если люди, создающие бизнес-правила, также будут их реализовывать.
Кроме того, нельзя недооценивать значение при удалении цикла Recompile-Retest-Redeploy, который может возникнуть в результате простого изменения правила, если правила встроены в код. Часто есть несколько команд, которые участвуют в создании благословения для сборки, и использование движка правил может сделать большую часть этого ненужным.
Я написал механизм правил для клиента. Самая большая победа была в том числе всех заинтересованных сторон. Движок может запустить (или воспроизвести) запрос и объяснить, что происходит в тексте. Деловые люди могут посмотреть на текстовое описание и быстро указать нюансы в правилах, исключениях и других особых случаях. Как только деловая сторона была вовлечена, проверка стала намного лучше, потому что было легко получить их вклад. Кроме того, механизм правил может работать отдельно от других частей базы кода приложения, поэтому вы можете использовать его в разных приложениях.
Дело в том, что некоторые программисты не любят учиться слишком многому. Механизмы правил и правила, которые вы в них включаете, вместе с тем, что их реализует, могут быть немного сложными. Хотя хорошая система может легко обрабатывать больные и искаженные сети логики (или часто нелогичные;), это не так просто, как кодировать кучу операторов if (независимо от того, что некоторые из простых механизмов правил) делать). Механизм правил дает вам инструменты для управления отношениями правил, но вы все равно должны иметь возможность представить все это в своем уме. Иногда это похоже на жизнь в фильме Бразилия . :)
Это (как и все остальное) зависит от вашего приложения. Для некоторых приложений (обычно тех, которые никогда не меняются, или правила лучше всего подходят для реальных констант, то есть не будут заметно меняться в течение эонов, например, физических свойств и формул), не имеет смысла использовать механизм правил, это просто вносит дополнительную сложность и требует от разработчика большего набора навыков.
Для других приложений это действительно хорошая идея. Возьмите, например, обработку заказов (заказы - это что угодно, от выставления счетов до обработки валютных операций), время от времени происходит небольшое изменение в каком-либо соответствующем законе или кодексе (в юридическом смысле), который требует от вас выполнения нового требования (например, налога с продаж). Классика). Вместо того, чтобы пытаться навязать свое старое приложение в этой новой ситуации, когда внезапно возникает мысль о налоге с продаж, где, как и раньше, легче адаптировать набор правил, чем вмешиваться в потенциально большой набор вашего кода.
Тогда следующая поправка от вашего местного правительства требует, чтобы вы сообщали обо всех продажах по определенным критериям, а не вам приходилось добавлять и это тоже. В конце концов вы получите очень сложный код, с которым будет довольно сложно справиться, когда вы развернетесь и захотите восстановить действие одного из правил, не влияя на все остальные ...
До сих пор все были очень позитивны в отношении механизмов правил, но я советую читателю быть осторожнее. Когда проблема становится немного более сложной, вы можете внезапно обнаружить, что весь механизм правил был сделан неподходящим или намного более сложным, чем в более мощном языке. Кроме того, для многих проблем механизмы правил не смогут легко обнаружить свойства, которые значительно сокращают время выполнения и объем памяти, необходимый для оценки состояния. Существует относительно немного ситуаций, в которых я бы предпочел механизм правил, а не систему внедрения зависимостей или более динамичный язык программирования.
" но на самом деле, сколько приложений действительно имеет столько изменений? "
Честно говоря, каждое приложение, над которым я работал, претерпело серьезные изменения в рабочем процессе и / или логике от концепции до задолго до развертывания. Это причина номер один для "технического обслуживания" программирование ...
Реальность такова, что вы не можете думать обо всем заранее, отсюда и причина гибких процессов. Кроме того, БА, кажется, всегда упускает что-то жизненно важное, пока оно не будет найдено в ходе испытаний.
Механизмы правил заставляют вас по-настоящему отделить бизнес-логику от представления и хранения. Кроме того, если вы используете правильный двигатель, ваши БА могут добавлять и удалять логику по мере необходимости. Как сказал Крис Марасти-Георг, это ложится бременем на БА. Но более того, это позволяет БА получить именно то, что они просят.
Механизм правил - это победа в настраиваемом приложении, в котором вам не нужно делать пользовательские сборки, если этого можно избежать. Они также хорошо умеют централизовать большие базы правил и алгоритмов, такие как Rete эффективны для быстрого сопоставления с большие наборы правил.
Уже много хороших ответов, но хотелось бы добавить пару вещей:
<Ол>Я считаю, что правила, процессы и механизмы обработки данных (базы данных a.k.a.) по сути похожи. Но по какой-то причине мы никогда не говорим, что «черный ящик» подсистемы персистентности плох.
Во-вторых, из моего POV анемичная модель - это не та модель, которая легка в реализации поведения, а та, которая сама по себе легка в поведении . Фактический метод, который описывает доступное поведение в объекте модели домена, не должен выполняться самим объектом.
Самым сложным из моего опыта в Rule Engines является то, что:
<Ол>