Kiedy nie należy używać silnika Rules? [zamknięte]

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

1. w poprzednim projekcie zauważyłem, że pliki reguł (projekt używał Drools) zawierały dużo kodu Javy, w tym pętle, funkcje itp. Były to zasadniczo pliki java maskujące się jako plik reguł. Kiedy zapytałem architekta o jego uzasadnienie dla projektu, powiedziano mi, że " zasady nigdy nie miały być utrzymywane przez biznes użytkowników".

Lesson: są one nazywane "regułami biznesowymi" nie bez powodu, nie używaj reguł, gdy nie możesz zaprojektować systemu, który może być łatwo utrzymywany/rozumiany przez użytkowników biznesowych.

1. inny przypadek; projekt stosował reguły, ponieważ wymagania były źle zdefiniowane/zrozumiane i często zmieniane. Rozwiązanie zespołu programistów polegało na szerokim wykorzystaniu reguł, aby uniknąć częstych wdrożeń kodu.

Lekcja : wymagania często się zmieniają podczas początkowe zmiany w wydaniu i nie gwarantują korzystania z zasad. Używaj zasad, gdy Twoja firma często się zmienia(Nie wymagania). Np: - oprogramowanie, które robi swoje podatki zmieni każdego roku jak zmiany prawa podatkowego i korzystanie z zasad jest doskonałym pomysłem. Wersja 1.0 aplikacji internetowej będzie się często zmieniać, gdy użytkownicy będą identyfikować nowe wymagania, ale ustabilizuje się w czasie. Nie używaj reguł jako alternatywy dla kodu deploy. ​

Jestem wielkim fanem silników zasad biznesowych, ponieważ może pomóc ci znacznie ułatwić ż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 spraw 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 przypadków i określić, czy masz nakładanie się między regułą na stronie 1 kodu i kolejny ze strony 5. Ogólnie rzecz biorąc, mieliśmy ponad 300 takich zasad osadzonych w kodzie.

Kiedy otrzymaliśmy nowy wymóg rozwoju, dla czegoś o nazwie Accounting Destination, który polegał na traktowaniu ponad 3000 zasad, wiedziałem, że coś musi się zmienić. Wtedy pracowałem nad prototypem, który później stał się rodzicem tego, co Teraz jest niestandardowym silnikiem reguł biznesowych, zdolnym do obsługi wszystkich standardowych operatorów SQL. Początkowo używaliśmy Excela jako narzędzia do tworzenia a później stworzyliśmy ASP.net aplikacja, która pozwoli użytkownikom biznesowym definiować własne reguły biznesowe, bez konieczności pisania kodu. Teraz system działa poprawnie, z bardzo małą ilością błędów i zawiera ponad 7000 reguł obliczania tego miejsca księgowania. Nie wydaje mi się, żeby taki scenariusz był możliwy tylko przez hard-coding. Użytkownicy są bardzo zadowoleni, że mogą definiować własne zasady bez stawania się ich wąskim gardłem.

Mimo to istnieją granice takie podejście:

• musisz mieć zdolnych użytkowników biznesowych, którzy doskonale rozumieją biznes firmy.
• istnieje znaczne obciążenie przeszukiwaniem całego systemu (w naszego przypadku hurtowni danych), w celu ustalenia wszystkich zakodowanych warunki, które mają sens przekładać się na zasady, które mają być obsługiwane przez silnik reguł biznesowych. Musieliśmy również zadbać o to, aby te wstępne szablony, aby były w pełni zrozumiałe dla użytkowników biznesowych.
• potrzebujesz mieć aplikację służącą do tworzenia reguł, w której zaimplementowano algorytmy wykrywania nakładających się reguł biznesowych. W przeciwnym razie skończysz z wielkim bałaganem, gdzie nikt już nie rozumie wyników, które otrzymują. Jeśli masz błąd w komponencie generycznym, takim jak Niestandardowy silnik reguł biznesowych, debugowanie i angażowanie rozbudowanych testów może być bardzo trudne, 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 napisane: 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 ich tworzeniem, bez konieczności przechodzenia do działu IT za każdym razem, gdy muszą coś zmodyfikować. Zmniejsza to również obciążenie zespołów programistycznych IT, które mogą teraz skupić się na budowaniu rzeczy z bardziej dodanymi wartość.

Pozdrawiam,

Nicolae

Jedyny poit jaki zauważyłem to "miecz obosieczny" to:

Oddanie logiki w ręce personelu nietechnicznego

Widziałem, że to działa świetnie, gdy masz jednego lub dwóch multidyscyplinarnych geniuszy po stronie nietechnicznej, ale widziałem również brak techniczności prowadzące do wzdęcia, więcej błędów, i ogólnie 4x koszty rozwoju / utrzymania.

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

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

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

Świetny 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, jeśli masz liniowy zestaw reguł, które mają zastosowanie tylko raz w dowolnej kolejności, aby uzyskać wynik, jest stworzenie interfejsu groovy i poproszenie programistów o napisanie i wdrożenie tych nowych reguł. Zaletą jest to, że jest bardzo szybki, ponieważ normalnie można przejść sesję hibernate lub sesję jdbc, a także dowolne parametry tak masz dostęp do wszystkich danych aplikacji, ale w wydajny sposób. Dzięki liście faktów może być wiele zapętleń/dopasowań, które naprawdę mogą spowolnić system down.....It to kolejny sposób na uniknięcie mechanizmu reguł i możliwość dynamicznego wdrażania (Tak, nasze reguły groovy zostały wdrożone w bazie danych i nie mieliśmy recursion....it albo spełnił regułę, albo nie). To tylko inna opcja.....AHA i jeszcze jedna zaleta to nie uczenie się składni reguł dla przychodzących programistów. Muszą się czegoś nauczyć. groovy, ale to jest bardzo blisko Javy, więc krzywa uczenia się jest znacznie lepsza.

To naprawdę zależy od kontekstu. Mechanizm reguł ma swoje miejsce, a powyższe jest tylko kolejną opcją, jeśli masz reguły dotyczące projektu, które możesz 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 możesz zamiast tego mieć groovy interfejs.....równie dynamicznie wdrażanych i nowych programistów dołączenie do zespołu może nauczyć się go szybciej niż język drools.(ale to moje zdanie)

Z mojego doświadczenia wynika, że silniki rules działają najlepiej, gdy są prawdziwe:

1. dobrze zdefiniowana Doktryna dla Twojej domeny problemowej
2. wysokiej jakości (najlepiej zautomatyzowane) dane, aby pomóc napędzać większość wejść
3. Dostęp do rzeczoznawców
4. programiści z doświadczeniem w tworzeniu systemów eksperckich

Jeśli brakuje którejkolwiek z tych czterech cech, nadal możesz znaleźć silnik reguł działa dla ciebie, ale za każdym razem próbowałem go z nawet 1 brakuje, Wpadłem w kłopoty.

To na pewno dobry początek. Inną rzeczą z silnikami reguł jest to, że niektóre rzeczy są dobrze zrozumiałe, deterministyczne i proste. Wstrzymanie wypłaty jest (lub być) w ten sposób. Możesz wyrazić to jako reguły, które byłyby rozwiązywane przez silnik reguł, ale możesz wyrazić te same reguły jako dość prostą tabelę wartości.

Więc silniki przepływu pracy są dobre, gdy wyrażasz długoterminowy proces, który będzie miał trwałe DANE. Zasady mogą zrób podobną rzecz, ale musisz zrobić dużo dodatkowej złożoności.

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

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 rzeczywistego 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 są niestabilne z natury, bardzo trudno jest utrzymać tę część podstawowego kodu technologicznego.
• silnik reguł zapewnia dużą elastyczność frameworka oraz łatwość zmiany i wdrożenia.
• Zasady silniki nie powinny być używane wszędzie, ale muszą być używane, gdy masz dużo polityk, w których zmiany są nieuniknione na bieżąco.

Nie bardzo rozumiem niektóre punkty takie jak:
a) ludzie biznesu muszą bardzo dobrze rozumieć biznes, lub;
b) niezgoda na ludzi biznesu nie muszą znać zasady.

Dla mnie, jako osoby dotykającej BRE, korzyścią z Bre jest tzw. dostosowanie systemu do zmian biznesowych, dlatego koncentruje się na adaptacji zmian.
Czy ma znaczenie, czy reguła ustawiona w czasie x różni się od reguły ustawionej w czasie y z powodu:
a) ludzie biznesu nie zrozumieć biznes, lub;
b) biznesmeni nie rozumieją zasad?

Jakiś czas temu pisałam o tym na blogu.

Możesz to sprawdzić tutaj - > http://www.codetoglory.com/?p=21

Naprawdę powinieneś go używać, gdy masz dynamiczne zasady, które stale się zmieniają, takie jak Ubezpieczenia,Handel i domeny walutowe.

Mam nadzieję, że mój artykuł na blogu da ci dobry przegląd.