Коли НЕ слід використовувати двигун правил? [зачинено]

У мене є досить пристойний перелік переваг використання Engine Engine, а також деякі причини їх використання. Мені потрібно перелік причин, чому НЕ слід використовувати систему Engine Engine

Найкраще, що у мене є, це:

Двигуни правил насправді не призначені для обробки робочого процесу чи виконання процесів, а також двигуни робочого процесу або засоби управління процесами не призначені для виконання правил.

Будь-які інші великі причини, чому ви не повинні їх використовувати?

Я дуже нервую, коли бачу людей, які використовують дуже великі набори правил (наприклад, на замовлення тисяч правил в одному наборі правил). Це часто трапляється, коли двигун правил - сингл, який сидить у центрі підприємства, сподіваючись, що дотримання правил DRY зробить їх доступними для багатьох додатків, які вимагають їх. Я б заперечував комусь, хто скаже мені, що двигун правил Рете з багатьма правилами добре зрозумілий. Мені невідомі будь-які інструменти, які можуть перевірити, щоб конфлікти не існували.

Я думаю, що набори правил розділення, щоб вони залишалися малими, - це кращий варіант. Аспекти можуть бути способом поділити загальне правило, встановлене між багатьма об'єктами.

Я вважаю за краще простіший, більш керований підходами підхід, де це можливо.

Я наведу два приклади з особистого досвіду, коли використання Engine Engine було поганою ідеєю, можливо, це допоможе: -

1. На минулому проекті я помітив, що файли правил (проект, який використовується Drools) містять багато Java-коду, включаючи петлі, функції тощо. Вони, по суті, були файлами java, що маскуються як файл правил. Коли я запитав архітектора про його міркування щодо дизайну, мені сказали, що "Правила ніколи не повинні дотримуватися бізнес-користувачі".

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

2. Інший випадок; Проект використовував правила, оскільки вимоги були погано визначені / зрозумілі та часто змінювалися. Рішенням команди розробників було широко використовувати правила, щоб уникнути частих розгортань коду.

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

Я великий шанувальник двигунів бізнес-правил, оскільки це може допомогти вам зробити життя набагато простішим як програміст. Одним із перших досвіду, який я мав під час роботи над проектом «Склад даних», було пошук збережених процедур, що містять складні структури CASE, що розтягуються на цілі сторінки. Налагоджувати це було кошмаром, оскільки було дуже важко зрозуміти логіку, застосовану в таких довгих структурах CASE, та визначити, чи є у вас перекриття між правилом на сторінці 1 коду та іншим зі сторінки 5. Загалом у нас було більше 300 таких правил, вбудованих у код.

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

Тим не менш, є такі обмеження:

• Потрібно мати ділових бізнес-користувачів, які чудово розуміють бізнес компанії.
• Існує значне навантаження на пошук всієї системи (у нашому випадку - Склад даних), щоб визначити всі жорстко кодовані умови, які мають сенс перекласти на правила, якими керується система управління діловими правилами. Ми також повинні були добре подбати про те, щоб ці початкові шаблони були повністю зрозумілими для бізнес-користувачів.
• Потрібно мати додаток, що використовується для створення правил, у якому реалізовані алгоритми виявлення перекриваються бізнес-правил. Інакше ти закінчишся великим безладом, коли ніхто більше не розуміє отриманих результатів. Якщо у вас є помилка в такому родовому компоненті, як Custom Business Rule Engine, виправити налагодження та застосувати широкі тести, щоб переконатися, що речі, які працювали раніше, також працюють зараз.

Детальніше про цю тему можна знайти у публікації, яку я написав: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

Загалом, найбільша перевага використання двигунів Business Rule Engine полягає в тому, що він дозволяє користувачам знову контролювати визначення та створення авторських правил, без необхідності відвідувати ІТ-відділ щоразу, коли потрібно щось змінювати. Це також зменшує навантаження над командами з розвитку ІТ, які тепер можуть зосередитись на створенні матеріалів з більшою доданою вартістю.

Ура,

Ніколае

Єдиний потік, який я помітив як "меч з двома кінцями":

передача логіки в руки не технічного персоналу

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

Таким чином, вам потрібно серйозно поставитися до своєї бази користувачів.

Я вважав, що стаття Алекса Пападімуліса була досить проникливою: http://thedailywtf.com/articles/soft_coding.aspx

Це не всеохоплююче, але у нього є деякі хороші моменти.

ВЕЛИКА стаття про те, коли не використовувати двигун правил ... (а також коли використовувати його) ....

http://www.jessrules.com/guidelines.shtml

Інший варіант - якщо у вас є лінійний набір правил, які застосовуються лише один раз у будь-якому порядку, щоб отримати результат, - це створити грубий інтерфейс і дозволити розробникам писати та розгортати ці нові правила. Перевага полягає в тому, що він злісно швидкий, тому що зазвичай ви проходите сеанс сплячки АБО jdbc, а також будь-які параметри, щоб у вас був доступ до всіх даних ваших програм, але ефективно. З переліком фактів може бути багато циклічного / відповідного, що дійсно може уповільнити роботу системи ... базу даних, і у нас не було рекурсії .... це або відповідало правилу, або його не було). Це просто інший варіант ..... о, і ще одна перевага - це не вивчення синтаксису правил для вхідних розробників.

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

В основному НЕ використовуйте двигун правил, якщо у вас простий набір правил і замість цього може бути громіздкий інтерфейс ..... так само, як динамічно розгортається, і нові розробники, що приєднуються до вашої команди, можуть навчитися йому швидше, ніж мова про дролл. (Але це моя думка)

На моєму досвіді, двигуни правил найкраще працюють, коли справедливо наступне:

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

Якщо будь-яка з цих чотирьох ознак відсутня, ви все ще можете виявити, що двигун правил працює для вас, але кожен раз, коли я спробував це з навіть 1 відсутнім, я стикався з проблемою.

Це, безумовно, вдалий початок. Інша річ, що стосується двигунів правил, - це те, що деякі речі добре зрозумілі, детерміновані та прямі. Утримання заборгованості із заробітної плати подібне (або раніше). Ви можете виразити це як правила, які вирішуються механізмом правил, але ви можете висловити ті ж правила, що і досить проста таблиця значень.

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

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

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

Я настійно рекомендую двигуни з бізнес-правилами, такі як Drools як відкритий джерело чи комерційні правила, такі як LiveRules.

• Коли у вас є велика кількість ділових політик, які мають мінливий характер, дуже важко підтримувати цю частину основного коду технологій.
• Двигун правил забезпечує велику гнучкість рамки та легко змінювати та розгортати.
• Двигуни правил не слід використовувати всюди, але їх потрібно використовувати, коли у вас є багато політик, коли зміни неминучі на регулярній основі.

Я не дуже розумію деякі моменти, такі як:
а) ділові люди повинні дуже добре розуміти бізнес, або;
б) незгоду ділових людей не потрібно знати правила.

Для мене, як людей, які просто торкаються BRE ，, користь BRE так називається, щоб система могла адаптуватися до змін у бізнесі, отже, вона орієнтована на адаптивність до змін.
Чи має значення, якщо правило, створене в момент часу x, відрізняється від правила, створеного в той час, через:
a) ділові люди не розуміють бізнес, або;
б) ділові люди не розуміють правил?