Была ли когда-нибудь по-настоящему успешной система, включающая механизм правил? [закрытый]

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

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

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

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

Как и все остальное, речь обычно идет о реализации, а не о самой технике.

Да, Microsoft имеет механизм бизнес-правил (BRE) в BizTalk, который успешно используется в течение многих лет. Я слышал, что у них были клиенты, которые покупали BizTalk (очень дорогой) только для BRE.

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

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

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

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

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

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

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

Я, конечно, есть, но не могу публично говорить о них, но, вероятно, вы взаимодействовали с одним несколько раз в этом году;)

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

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

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

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

Действительно.

Мой опыт ограничен (i)немногим и (ii) прологом; но я могу с уверенностью сказать, что механизм правил может помочь вам выразить пропозициональные понятия намного чище, чем процедурный код.

Механизмы правил обычно используются в страховом бизнесе. Я работал над системами с сотнями (600ish) правил, которые были реализованы в движке правил. Это сработало очень хорошо.

У вас есть кредитный рейтинг? Может быть, счет FICO? Это F air I saac CO rporation, разработчики двигателя правил Blaze.

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

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

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