Rules Engine-plusy i minusy

Myślę, że twoje obawy dotyczące anemicznych modeli domen są słuszne.

Widziałem dwie aplikacje znanego komercyjnego silnika Rete rules działającego w produkcji, gdzie pracuję. Uznałbym jeden za sukces, a drugi za porażkę.

Pomyślna aplikacja to aplikacja drzewa decyzyjnego, składająca się z ~10 drzew po ~ 30 punktów gałęzi każdy. Silnik reguł ma interfejs użytkownika, który pozwala ludziom biznesowym zachować zasady.

Mniej udana aplikacja ma ~3000 zasad / align = "left" / Nikt nie ma pojęcia, czy istnieją sprzeczne zasady po dodaniu nowego. Niewiele jest zrozumienia algorytmu Rete, a wiedza o produkcie opuściła firmę, więc stała się czarną skrzynką, która jest nietykalna i niewykonalna. Na cykl wdrażania nadal wpływają zmiany reguł - w przypadku zmiany reguł należy wykonać kompletny test regresji. Pamięć też była problemem.

Stąpałbym lekko. Gdy zbiór reguł jest skromny łatwo zrozumieć zmiany, takie jak uproszczona próbka e-maila podana powyżej. Kiedy liczba zasad wzrośnie do setek, myślę, że możesz mieć problem.

Martwiłbym się również, że silnik reguł stanie się wąskim gardłem Singletona w Twojej aplikacji.

Nie widzę nic złego w używaniu obiektów jako sposobu na partycję, która rządzi przestrzenią silnika. Osadzanie zachowań w obiektach, które podlegają prywatnemu silnikowi reguł wydaje mi się w porządku. Problemy pojawią się, gdy silnik zasad wymaga stanu, który nie jest częścią jego obiektu, aby poprawnie strzelać. Ale to kolejny przykład trudnego projektowania.

Silniki reguł mogą oferować wiele wartości, w niektórych przypadkach.

Po pierwsze, wiele silników reguł działa w bardziej deklaratywny sposób. Bardzo prostym przykładem może być AWK, gdzie można przypisać wyrażenia regularne do bloków kodu. Gdy regex jest widziany przez skaner plików, blok kodu jest wykonywany.

Widać, że w tym przypadku, jeśli masz, powiedzmy, duży plik AWK i chcesz dodać kolejną "regułę", możesz łatwo przejść do dołu pliku, dodać regex i logikę i gotowe z nim. W szczególności, w przypadku wielu aplikacji, nie jesteś szczególnie zaniepokojony tym, co robią inne zasady, a zasady tak naprawdę nie współgrają ze sobą.

W ten sposób plik AWK staje się bardziej "zupą reguł". Ta natura "zupy reguł" pozwala ludziom skupić się bardzo mocno na swojej domenie z niewielką troską o wszystkie inne zasady, które mogą być w systemie.

Na przykład Frank jest zainteresowany zamówieniami o łącznej wartości ponad 1000 usd, więc wprowadza zasadę system, który go interesuje. "Jeśli zamówienie.razem > 1000 następnie napisz do Franka".

Tymczasem Sally chce wszystkich rozkazów z zachodniego wybrzeża: "jeśli rozkaz.source = = "WEST_COAST" then email Sally".

Tak więc w tym trywialnym, wymyślonym przypadku widać, że porządek może spełniać obie reguły, jednak obie reguły są od siebie niezależne. Zamówienie na 1200 dolarów z Zachodniego Wybrzeża zawiadamia Franka i Sally. Kiedy Frank nie będzie się już martwił, po prostu wyciągnie jego wykluczenie z zupy.

Dla wielu sytuacje, ta elastyczność może być bardzo potężna. Może również, jak w tym przypadku, być narażony na użytkowników końcowych dla prostych zasad. Korzystanie z wyrażeń wysokiego poziomu i być może lekkiego skryptowania.

Teraz, oczywiście, w skomplikowanym systemie istnieją różnego rodzaju powiązania, które mogą się zdarzyć, i dlatego cały system nie jest "zrobiony z regułami". Ktoś, gdzieś będzie rządził zasadami, które nie wymkną się spod kontroli. Ale to niekoniecznie zmniejsza wartość, jaką taki system może zapewnij.

Pamiętaj, że nie dotyczy to nawet systemów eksperckich, gdzie reguły strzelają do danych, które reguły mogą tworzyć, ale prostszy system reguł.

W każdym razie, mam nadzieję, że ten przykład pokazuje, jak system reguł może pomóc w powiększeniu większej aplikacji.

Największym profesjonalistą, jaki widziałem dla silników reguł jest to, że pozwala właścicielom reguł biznesowych wdrażać reguły biznesowe, zamiast nakładać na programistów obciążenie. Nawet jeśli masz zwinny proces, w którym stale otrzymujesz informacje zwrotne od interesariuszy i przechodzisz przez szybkie iteracje, nadal nie osiągniesz poziomu wydajności, który można osiągnąć dzięki wdrożeniu ich przez osoby tworzące reguły biznesowe.

Poza tym nie można podkreslić wartość w usuwaniu cyklu recompile-retest-reeploy, który może wynikać z prostej zmiany reguły, jeśli reguły są osadzone w kodzie. Często jest kilka zespołów, które są zaangażowane w umieszczenie błogosławieństwa na kompilacji, a korzystanie z silnika reguł może sprawić, że wiele z tego nie będzie potrzebne.

Napisałem silnik reguł dla klienta. Największe zwycięstwo odniosły wszystkie zainteresowane strony. Silnik mógł uruchomić (lub odtworzyć) zapytanie i wyjaśnić, co się dzieje w tekście. Ludzie biznesu mogli przyjrzeć się opisowi tekstu i szybko wskazać niuanse w przepisach, wyjątkach i innych szczególnych przypadkach. Po zaangażowaniu strony biznesowej Walidacja stała się znacznie lepsza, ponieważ łatwo było uzyskać ich wkład. Dodatkowo silnik rules może żyć oddzielnie od innych części baza kodu aplikacji, dzięki czemu można go używać w różnych aplikacjach.

To (jak Wszystko inne) zależy od twojej aplikacji. W przypadku niektórych aplikacji (Zwykle tych, które nigdy się nie zmieniają lub reguły są najlepsze na rzeczywistych stałych, tzn. nie zmienią się zauważalnie w eonach, na przykład właściwości fizyczne i formuły) nie ma sensu używać silnika reguł, po prostu wprowadza dodatkową złożoność i wymaga od programisty większego zestawu umiejętności.

Dla innych aplikacji to naprawdę dobry pomysł. Weźmy na przykład przetwarzanie zamówień (zamówienia są wszystko, od fakturowania po transakcje walutowe), co jakiś czas następuje drobna zmiana odpowiedniego prawa lub kodeksu (w sensie sądowym), które wymaga spełnienia nowego wymogu (na przykład podatku od sprzedaży, klasyka). Zamiast próbować wymusić starą aplikację w tej nowej sytuacji, w której nagle musisz myśleć o podatku od sprzedaży, gdzie jak wcześniej nie, łatwiej jest dostosować swój zestaw reguł, zamiast mieszać się w potencjalnie duży zestaw Twój kod.

W takim razie kolejna nowelizacja twojego Samorządu wymaga raportowania wszystkich sprzedaży w określonych kryteriach, a nie musisz wchodzić i to też dodawać. W końcu otrzymasz bardzo złożony kod, który okaże się dość trudny do zarządzania, gdy zawrócisz i chcesz przywrócić efekt jednej z reguł, bez wpływu na wszystkie pozostałe...

Wszyscy do tej pory byli bardzo pozytywnie nastawieni do zasad, ale radzę czytelnikowi zachować ostrożność. Gdy problem staje się nieco bardziej skomplikowany, może się okazać, że cały silnik reguł stał się nieodpowiedni lub znacznie bardziej skomplikowany niż w bardziej wydajnym języku. Ponadto w przypadku wielu problemów silniki reguł nie będą w stanie łatwo wykryć właściwości, które znacznie zmniejszają czas wykonywania i pamięć oceny warunku. Jest stosunkowo niewiele sytuacje, w których wolałbym silnik reguł niż Framework iniekcji zależności lub bardziej dynamiczny język programowania.

" ale naprawdę, ile aplikacji ma tak wiele zmian?"

Szczerze mówiąc, każda aplikacja, nad którą pracowałem przeszedł poważne przepływ pracy i / lub zmiany logiczne od koncepcji do dobrze po wdrożeniu. To najważniejszy powód programowania" konserwacji"...

Rzeczywistość jest taka, że nie można myśleć o wszystkim z góry, stąd powód zwinnych procesów. Co więcej, BA zawsze zdaje się tęsknić za czymś ważnym, dopóki nie zostanie znaleziony w testach.

Rule Engines force you aby naprawdę oddzielić logikę biznesową od prezentacji i przechowywania. Ponadto, jeśli używasz odpowiedniego silnika, Twoje BA mogą dodawać i usuwać logikę w razie potrzeby. Jak powiedział Chris Marasti-Georg, stawia to na BA. Ale co więcej, pozwala BA uzyskać dokładnie to, o co proszą.

Silnik reguł jest wygraną w konfigurowalnej aplikacji, w której nie chcesz robić niestandardowych kompilacji, jeśli można tego uniknąć. Są również dobre w centralizacji dużych baz reguł i algorytmy, takie jak Rete {[2] } są skuteczne w szybkim dopasowywaniu do dużych zbiorów reguł.

Wiele dobrych odpowiedzi już ale chciałem dodać kilka rzeczy:

1. w automatyzacji decyzji o dowolnej złożoności krytyczna rzecz szybko staje się zdolność do zarządzania, a nie wykonywania logiki. Silnik reguł nie pomoże w tym - musisz pomyśleć o możliwościach zarządzania regułami, jakie ma system zarządzania regułami biznesowymi. Większość komercyjnych i open source ' owych silników reguł ewoluowała w systemy zarządzania regułami z repozytoriami, raportujące na użycie reguł, wersjonowanie itp. Repozytorium reguł, uporządkowane w spójne zestawy reguł, które można zaaranżować w celu podejmowania decyzji biznesowych, jest o wiele łatwiejsze do zarządzania niż tysiące linii kodu lub zupa reguł.
2. Istnieje wiele sposobów na użycie deklaratywnego, opartego na regułach podejścia. Używanie reguł do zarządzania interfejsem użytkownika lub jako część definiowania procesu może być bardzo skuteczne. Najcenniejszym zastosowaniem podejścia opartego na regułach jest jednak automatyzacja decyzji biznesowych i dostarczanie ich w sposób luźny Połączone Usługi decyzyjne, które pobierają dane wejściowe, wykonują reguły i zwracają odpowiedź-decyzję. Rzecz z nich jako usługi, które odpowiadają na pytania dotyczące innych usług, takich jak " Czy ten klient jest dobrym ryzykiem kredytowym "lub" jaki rabat powinienem dać temu klientowi za to zamówienie lub " jaka jest najlepsza sprzedaż Krzyżowa dla tego klienta w tym czasie. Te usługi decyzyjne mogą być bardzo skutecznie budowane przy użyciu systemu zarządzania regułami i pozwalają na łatwą integrację analiz w czasie, coś wiele decyzji skorzystaj z.

Widzę, że silniki reguł, procesów i danych (a. k. a. baz danych) są zasadniczo podobne. Ale z jakiegoś powodu nigdy nie mówimy, że blackboxing podsystemu trwałości jest zły.

Po drugie, z mojego POV, model anemiczny nie jest taki, który jest lekki w implementacji zachowań, jest taki, który jest lekki w samych zachowań . Rzeczywista metoda opisująca dostępne zachowanie w obiekcie modelu domeny nie musi być wykonywana przez sam obiekt.

Największą złożonością z mojego doświadczenia w silnikach reguł jest to, że:

1. od OOP POV to prawdziwy ból do refaktoryzacji i testowania reguł napisanych w języku deklaratywnym podczas refaktoryzacji kodu, który na nie wpływa.
2. często powinniśmy zawsze myśleć o kolejności wykonywania zasad, które zmieniają się w bałagan, gdy jest ich dużo.
3. niektóre drobne zmiany mogą spowodować nieprawidłowe zachowanie reguł prowadzących do błędów produkcyjnych. W praktyce nie zawsze jest możliwe przykryj wszystkie przypadki testami z góry.
4. reguły mutujące obiekty używane w innych również zwiększają złożoność, powodując, że deweloperzy dzielą je na etapy.