Kiedy NIE należy używać silnika reguł? [Zamknięte]

Mam całkiem przyzwoitą listę zalet korzystania z silnika reguł, a także kilka powodów, aby ich używać, potrzebuję listy powodów, dla których NIE powinieneś używać silnika reguł

Najlepsze, jakie do tej pory mam, to:

Mechanizmy reguł nie są tak naprawdę przeznaczone do obsługi przepływu pracy lub wykonywania procesów, podobnie jak silniki przepływu pracy lub narzędzia do zarządzania procesami przeznaczone do wykonywania reguł.

Jakieś inne ważne powody, dla których nie powinieneś ich używać?

Bardzo się denerwuję, gdy widzę ludzi używających bardzo dużych zestawów reguł (np. Rzędu tysięcy reguł w jednym zestawie). Dzieje się tak często, gdy silnik reguł jest singletonem znajdującym się w centrum przedsiębiorstwa w nadziei, że przestrzeganie reguł DRY sprawi, że będą dostępne dla wielu aplikacji, które ich wymagają. Przeciwstawiłbym się komukolwiek, kto powiedziałby mi, że silnik reguł Rete z tak wieloma regułami jest dobrze zrozumiany. Nie znam żadnych narzędzi, które mogą sprawdzić, czy konflikty nie istnieją.

Myślę, że zestawy reguł partycjonowania, aby były małe, są lepszym rozwiązaniem. Aspekty mogą być sposobem na udostępnienie wspólnego zestawu reguł dla wielu obiektów.

Wolę prostsze, bardziej oparte na danych podejście, gdy tylko jest to możliwe.

Podam 2 przykłady z własnego doświadczenia, w których użycie silnika reguł było złym pomysłem, może to pomoże: -

1. W poprzednim projekcie zauważyłem, że pliki reguł (projekt korzystał z Drools) zawierały dużo kodu java, w tym pętle, funkcje itp. Były to zasadniczo pliki java udające plik reguł. Kiedy zapytałem architekta o jego uzasadnienie dla projektu, powiedziano mi, że „Zasady nigdy nie miały być utrzymywane przez użytkowników biznesowych”.

Lekcja : Nie bez powodu nazywane są one „Regułami biznesowymi”. Nie używaj reguł, gdy nie możesz zaprojektować systemu, który może być łatwo utrzymywany / zrozumiały dla użytkowników biznesowych.

2. Inna sprawa; W projekcie zastosowano reguły, ponieważ wymagania były słabo zdefiniowane / zrozumiane i często się zmieniały. Rozwiązanie zespołu programistów polegało na szerokim użyciu reguł, aby uniknąć częstego wdrażania kodu.

Lekcja : Wymagania często się zmieniają podczas początkowych zmian w wydaniu i nie gwarantują użycia reguł. Użyj reguł, gdy Twoja firma często się zmienia (nie wymagania). Np .: - Oprogramowanie, które oblicza Twoje podatki, będzie się zmieniać co roku, gdy zmieniają się przepisy podatkowe, a stosowanie reguł to doskonały pomysł. Wersja 1.0 aplikacji internetowej będzie się często zmieniać, gdy użytkownicy będą identyfikować nowe wymagania, ale z czasem będzie się stabilizować. Nie używaj reguł jako alternatywy dla wdrażania kodu. Wcześniejsze

Jestem wielkim fanem silników reguł biznesowych, ponieważ mogą one znacznie ułatwić Ci życie jako programista. Jednym z pierwszych doświadczeń, jakie miałem podczas pracy nad projektem hurtowni danych, było znalezienie procedur składowanych zawierających skomplikowane struktury CASE rozciągające się na całe strony. Debugowanie było koszmarem, ponieważ bardzo trudno było zrozumieć logikę stosowaną w tak długich strukturach CASE i określić, czy masz nakładanie się reguły na stronie 1 kodu z inną ze strony 5. Ogólnie ponad 300 takich reguł osadzonych w kodzie.

Kiedy otrzymaliśmy nowe wymaganie dotyczące rozwoju czegoś, co nazywa się Accounting Destination, które obejmowało obsługę ponad 3000 reguł, wiedziałem, że coś musi się zmienić. Pracowałem wtedy nad prototypem, który później stał się rodzicem tego, co teraz jest silnikiem Custom Business Rule, zdolnym do obsługi wszystkich standardowych operatorów SQL. Początkowo używaliśmy Excela jako narzędzia do tworzenia treści, a później stworzyliśmy aplikację ASP.net, która pozwoli użytkownikom biznesowym definiować własne reguły biznesowe bez konieczności pisania kodu. Teraz system działa dobrze, z bardzo małą liczbą błędów i zawiera ponad 7000 reguł obliczania tego miejsca docelowego księgowania. Nie sądzę, by taki scenariusz był możliwy po prostu na sztywno.

Jednak takie podejście ma pewne ograniczenia:

• Musisz mieć zdolnych użytkowników biznesowych, którzy doskonale rozumieją działalność firmy.
• Przeszukiwanie całego systemu (w naszym przypadku hurtowni danych) wymaga dużego nakładu pracy, aby określić wszystkie zakodowane na stałe warunki, które mają sens w przełożeniu na reguły obsługiwane przez Business Rule Engine. Musieliśmy również zadbać o to, aby te wstępne szablony były w pełni zrozumiałe dla użytkowników biznesowych.
• Potrzebujesz aplikacji służącej do tworzenia reguł, w której zaimplementowane są algorytmy wykrywania nakładających się reguł biznesowych. W przeciwnym razie skończysz z wielkim bałaganem, w którym nikt już nie zrozumie wyników, jakie osiągają. W przypadku błędu w komponencie ogólnym, takim jak niestandardowy silnik reguł biznesowych, debugowanie może być bardzo trudne i wymaga obszernych testów, aby upewnić się, że rzeczy, które działały wcześniej, działają również teraz.

Więcej szczegółów na ten temat można znaleźć w poście, który napisałem: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

Ogólnie rzecz biorąc, największą zaletą korzystania z silników reguł biznesowych jest to, że pozwala użytkownikom odzyskać kontrolę nad definicjami reguł biznesowych i tworzeniem treści, bez konieczności udawania się do działu IT za każdym razem, gdy muszą coś zmienić. Zmniejsza również obciążenie pracą zespołów programistów IT, które mogą teraz skupić się na tworzeniu rzeczy o większej wartości dodanej.

Twoje zdrowie,

Nicolae

Jedyny punkt, który zauważyłem jako „miecz obosieczny”, to:

oddanie logiki w ręce nietechnicznego personelu

Widziałem, jak to działa świetnie, gdy masz jednego lub dwóch multidyscyplinarnych geniuszy po stronie nietechnicznej, ale widziałem również brak techniki prowadzący do nadęcia, większej liczby błędów i ogólnie 4x kosztów rozwoju / utrzymania.

Dlatego musisz poważnie rozważyć swoją bazę użytkowników.

Myślałem, że artykuł Alexa Papadimoulisa był dość wnikliwy: http://thedailywtf.com/articles/soft_coding.aspx

Nie jest to wyczerpujące, ale ma kilka dobrych punktów.

WIELKI artykuł o tym, kiedy nie używać silnika reguł ... (a także kiedy go używać) ....

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

Inną opcją jest to, że jeśli masz liniowy zestaw reguł, które mają zastosowanie tylko raz w dowolnej kolejności, aby uzyskać wynik, jest stworzenie świetnego interfejsu i poproszenie programistów o napisanie i wdrożenie tych nowych reguł. Zaletą jest to, że jest niesamowicie szybki, ponieważ normalnie przechodziłbyś sesję hibernacji LUB sesję jdbc, a także wszelkie parametry, dzięki czemu masz dostęp do wszystkich danych aplikacji, ale w efektywny sposób. Z listą faktów może istnieć wiele zapętleń / dopasowań, które naprawdę mogą spowolnić system ..... To kolejny sposób na uniknięcie silnika reguł i możliwość dynamicznego wdrażania (tak, nasze świetne reguły zostały wdrożone w baza danych i nie mieliśmy rekursji ... albo spełniła regułę, albo nie). To tylko kolejna opcja… och i jeszcze jedna korzyść to brak nauki składni reguł dla przyszłych programistów.

To naprawdę zależy od twojego kontekstu. Silnik reguł ma swoje miejsce, a powyższa opcja to tylko kolejna opcja, jeśli masz w projekcie reguły, które możesz chcieć wdrożyć dynamicznie w bardzo uproszczonych sytuacjach, które nie wymagają silnika reguł.

Zasadniczo NIE używaj silnika reguł, jeśli masz prosty zestaw reguł i zamiast tego możesz mieć fajny interfejs ..... tak samo dynamicznie wdrażalny, a nowi programiści dołączający do twojego zespołu mogą nauczyć się go szybciej niż języka ślinek. (Ale to jest moja opinia)

Z mojego doświadczenia wynika, że ​​silniki reguł działają najlepiej, gdy są spełnione następujące warunki:

1. Dobrze zdefiniowana doktryna dla Twojej problematycznej domeny
2. Dane wysokiej jakości (najlepiej zautomatyzowane), aby pomóc w generowaniu większości danych wejściowych
3. Dostęp do ekspertów merytorycznych
4. Programiści z doświadczeniem w tworzeniu systemów eksperckich

Jeśli brakuje którejkolwiek z tych czterech cech, nadal może się okazać, że silnik reguł działa dla Ciebie, ale za każdym razem, gdy próbuję go z brakiem choćby jednej, mam kłopoty.

To z pewnością dobry początek. Inną rzeczą w przypadku silników reguł jest to, że niektóre rzeczy są dobrze zrozumiane, deterministyczne i proste. Potrącenie z listy płac jest (lub powinno być) takie. Możesz to wyrazić jako reguły, które zostaną rozwiązane przez silnik reguł, ale możesz wyrazić te same reguły, co dość prosta tabela wartości.

Tak więc silniki przepływu pracy są dobre, gdy wyrażasz długoterminowy proces, który będzie miał trwałe dane. Silniki reguł mogą robić podobne rzeczy, ale musisz zrobić dużo dodatkowej złożoności.

Silniki reguł są dobre, gdy masz skomplikowane bazy wiedzy i potrzebujesz wyszukiwania. Silniki reguł mogą rozwiązywać skomplikowane problemy i mogą być szybko dostosowywane do zmieniających się sytuacji, ale nakładają dużą złożoność na podstawową implementację.

Wiele algorytmów decyzyjnych jest na tyle prostych, że można je wyrazić jako prosty program oparty na tabelach, bez złożoności wynikającej z prawdziwego silnika reguł.

Zdecydowanie polecam silniki reguł biznesowych, takie jak Drools, jako open source lub Commercial Rules Engine, takie jak LiveRules.

• Kiedy masz wiele polityk biznesowych, które mają niestabilny charakter, bardzo trudno jest utrzymać tę część kodu podstawowej technologii.
• Silnik reguł zapewnia dużą elastyczność struktury i jest łatwy do zmiany i wdrożenia.
• Mechanizmów reguł nie należy używać wszędzie, ale należy go używać, gdy istnieje wiele zasad, w których regularne zmiany są nieuniknione.

Naprawdę nie rozumiem niektórych punktów, takich jak:
a) ludzie biznesu muszą bardzo dobrze rozumieć biznes lub;
b) brak zgody co do ludzi biznesu nie musi znać reguły.

Dla mnie, jako osoby po prostu dotykającej BRE ， korzyści płynące z BRE to tak zwane umożliwienie systemowi dostosowania się do zmian biznesowych, dlatego skupia się na adaptacji do zmian.
Czy ma znaczenie, czy reguła ustawiona w czasie x różni się od reguły skonfigurowanej w czasie y, ponieważ:
a) ludzie biznesu nie rozumieją biznesu lub;
b) biznesmeni nie rozumieją zasad?