Rules Engine - Vor- und Nachteile

Ich prüfe ein Projekt, das eine sogenannte Regel-Engine verwendet . Kurz gesagt, es ist eine Möglichkeit, Geschäftslogik aus Anwendungscode zu externalisieren.

Dieses Konzept ist für mich völlig neu und ich bin ziemlich skeptisch. Nachdem die Leute in den letzten Jahren über anämische Domänenmodelle gesprochen haben , stelle ich den Rules Engine-Ansatz in Frage. Für mich scheinen sie eine großartige Möglichkeit zu sein, ein Domain-Modell zu SCHWACHEN. Angenommen, ich mache eine Java-Webanwendung, die mit einer Rules Engine interagiert. Dann entscheide ich mich für eine Android-App, die auf derselben Domain basiert. Wenn ich nicht möchte, dass die Android-App auch mit der Rules Engine interagiert, muss ich auf die bereits geschriebene Geschäftslogik verzichten.

Da ich noch keine Erfahrung mit ihnen habe, nur Neugier, war ich interessiert zu erfahren, welche Vor- und Nachteile die Verwendung einer Rules Engine hat. Der einzige Vorteil, den ich mir vorstellen kann, ist, dass Sie nicht Ihre gesamte Anwendung neu erstellen müssen, um eine Geschäftsregel zu ändern (aber wie viele Apps haben wirklich so viele Änderungen?). Aber die Verwendung einer Rules Engine zur Lösung dieses Problems klingt für mich wie ein Pflaster über einer Schrotflintenwunde.

UPDATE - Seit dem Schreiben dieses Artikels hat der Gott selbst, Martin Fowler, über die Verwendung einer Regel-Engine gebloggt .

Die meisten Regel-Engines, die ich gesehen habe, werden vom Systemcode als Black Box angesehen. Wenn ich ein Domänenmodell erstellen würde, würde ich wahrscheinlich wollen, dass bestimmte Geschäftsregeln dem Domänenmodell eigen sind, z. B. Geschäftsregeln, die mir mitteilen, wenn ein Objekt ungültige Werte hat. Auf diese Weise können mehrere Systeme das Domänenmodell gemeinsam nutzen, ohne die Geschäftslogik zu duplizieren. Ich könnte jedes System denselben Regeldienst verwenden lassen, um mein Domänenmodell zu validieren, aber dies scheint mein Domänenmodell zu schwächen (wie in der Frage ausgeführt). Warum? Da ich meine Geschäftsregeln nicht immer systemübergreifend durchsetzen muss, verlasse ich mich auf Systemprogrammierer, um zu bestimmen, wann die Geschäftsregeln durchgesetzt werden sollen (durch Aufrufen des Regeldienstes). Dies ist möglicherweise kein Problem, wenn das Domain-Modell vollständig ausgefüllt zu Ihnen kommt, kann jedoch problematisch sein, wenn Sie

Es gibt eine andere Klasse von Geschäftsregeln: Entscheidungsfindung. Beispielsweise muss eine Versicherungsgesellschaft möglicherweise das Risiko des Zeichnens eines Antragstellers klassifizieren und eine Prämie erzielen. Sie könnten diese Art von Geschäftsregeln in Ihr Domänenmodell einfügen, aber eine zentralisierte Entscheidung für solche Szenarien ist normalerweise wünschenswert und passt tatsächlich recht gut in eine serviceorientierte Architektur. Dies wirft die Frage auf, warum eine Regelengine und kein Systemcode. Der Ort, an dem eine Regelengine die bessere Wahl sein kann, ist der Ort, an dem sich Geschäftsregeln, die für die Entscheidung verantwortlich sind, im Laufe der Zeit ändern (wie einige andere Antworten gezeigt haben).

Mit Regel-Engines können Sie normalerweise Regeln ändern, ohne Ihr System neu zu starten oder neuen ausführbaren Code bereitzustellen (unabhängig davon, welche Versprechen Sie von einem Anbieter erhalten, stellen Sie sicher, dass Sie Ihre Änderungen in einer Nicht-Produktionsumgebung testen, da die Regel-Engine auch dann fehlerfrei ist Menschen ändern immer noch die Regeln). Wenn Sie denken: "Ich kann das tun, indem ich eine Datenbank zum Speichern von sich ändernden Werten verwende", haben Sie Recht. Eine Regel-Engine ist keine magische Box, die etwas Neues macht. Es soll ein Werkzeug sein, das eine höhere Abstraktionsebene bietet, sodass Sie sich weniger auf die Neuerfindung des Rads konzentrieren können. Viele Anbieter gehen noch einen Schritt weiter, indem Sie Vorlagen erstellen, damit Geschäftsbenutzer die Lücken ausfüllen können, anstatt eine Regelsprache zu lernen.

Ein Teil der Vorsicht bei Vorlagen: Vorlagen können niemals weniger Zeit in Anspruch nehmen als das Schreiben einer Regel ohne Vorlage, da die Vorlage mindestens die Regel beschreiben muss. Planen Sie höhere Anschaffungskosten ein (genauso, als würden Sie ein System erstellen, das eine Datenbank zum Speichern von Werten verwendet, die sich ändern, anstatt die Regeln direkt in den Systemcode zu schreiben) - der ROI liegt daran, dass Sie bei der zukünftigen Wartung des Systemcodes sparen .

Ich denke, Ihre Bedenken hinsichtlich anämischer Domänenmodelle sind berechtigt.

Ich habe zwei Anwendungen einer bekannten kommerziellen Rete-Regel-Engine gesehen, die in der Produktion ausgeführt wird, in der ich arbeite. Ich würde den einen als Erfolg und den anderen als Misserfolg betrachten.

Die erfolgreiche Anwendung ist eine Entscheidungsbaum-App, die aus ~ 10 Bäumen mit jeweils ~ 30 Verzweigungspunkten besteht. Die Regelengine verfügt über eine Benutzeroberfläche, über die Geschäftsleute die Regeln verwalten können.

Die weniger erfolgreiche Anwendung hat ~ 3000 Regeln in eine Regeldatenbank geschrieben. Niemand hat eine Ahnung, ob es widersprüchliche Regeln gibt, wenn eine neue hinzugefügt wird. Es gibt wenig Verständnis für den Rete-Algorithmus, und das Fachwissen mit dem Produkt hat das Unternehmen verlassen, so dass es zu einer Black Box geworden ist, die unantastbar und nicht nachvollziehbar ist. Der Bereitstellungszyklus ist weiterhin von Regeländerungen betroffen. Wenn Regeln geändert werden, muss ein vollständiger Regressionstest durchgeführt werden. Auch das Gedächtnis war ein Thema.

Ich würde leicht treten. Wenn ein Regelsatz von bescheidener Größe ist, sind Änderungen leicht zu verstehen, wie das oben angegebene vereinfachte E-Mail-Beispiel. Sobald die Anzahl der Regeln auf Hunderte steigt, haben Sie wahrscheinlich ein Problem.

Ich würde mir auch Sorgen machen, dass eine Regelengine zu einem Singleton-Engpass in Ihrer Anwendung wird.

Ich sehe nichts Falsches daran, Objekte als Mittel zur Partitionierung des Engine-Space zu verwenden. Das Einbetten von Verhalten in Objekte, die sich auf eine private Regelengine beschränken, scheint mir in Ordnung zu sein. Probleme treten auf, wenn die Regelengine einen Status benötigt, der nicht Teil ihres Objekts ist, um ordnungsgemäß ausgelöst zu werden. Aber das ist nur ein weiteres Beispiel dafür, dass Design schwierig ist.

Regel-Engines können in bestimmten Fällen viel Wert bieten.

Erstens arbeiten viele Regel-Engines deklarativer. Ein sehr grobes Beispiel wäre AWK, bei dem Sie Codeblöcken reguläre Ausdrücke zuweisen können. Wenn der Regex vom Dateiscanner erkannt wird, wird der Codeblock ausgeführt.

Sie können sehen, dass Sie in diesem Fall, wenn Sie beispielsweise eine große AWK-Datei hatten und noch eine weitere "Regel" hinzufügen möchten, problemlos zum Ende der Datei gehen, Regex und Logik hinzufügen und fertig sind es. Insbesondere sind Sie bei vielen Anwendungen nicht besonders daran interessiert, was die anderen Regeln tun, und die Regeln arbeiten nicht wirklich miteinander zusammen.

Somit wird die AWK-Datei eher zu einer "Regelsuppe". Diese "Regel-Suppe" -Natur ermöglicht es den Leuten, sich sehr eng auf ihre Domäne zu konzentrieren, ohne sich um alle anderen Regeln zu kümmern, die möglicherweise im System enthalten sind.

Zum Beispiel ist Frank an Bestellungen mit einem Gesamtvolumen von mehr als 1000 US-Dollar interessiert, also setzt er sich für das Regelsystem ein, an dem er interessiert ist. "WENN order.total> 1000 DANN Frank eine E-Mail senden".

In der Zwischenzeit möchte Sally alle Bestellungen von der Westküste: "WENN order.source == 'WEST_COAST' DANN Sally per E-Mail".

In diesem trivialen, erfundenen Fall können Sie also sehen, dass eine Bestellung beide Regeln erfüllen kann, beide Regeln jedoch unabhängig voneinander sind. Eine Bestellung über 1200 USD von der Westküste benachrichtigt sowohl Frank als auch Sally. Wenn Frank nicht mehr besorgt ist, wird er einfach seine Regel aus der Suppe ziehen.

In vielen Situationen kann diese Flexibilität sehr leistungsfähig sein. Wie in diesem Fall kann es auch Endbenutzern für einfache Regeln zur Verfügung gestellt werden. Verwenden von High-Level-Ausdrücken und möglicherweise leichtem Scripting.

Nun, klar, in einem komplizierten System können alle möglichen Zusammenhänge auftreten, und deshalb ist das gesamte System nicht "mit Regeln fertig". Jemand, irgendwo wird dafür verantwortlich sein, dass die Regeln nicht außer Kontrolle geraten. Dies verringert jedoch nicht unbedingt den Wert, den ein solches System bieten kann.

Beachten Sie, dass dies nicht einmal für Dinge wie Expertensysteme gilt, bei denen Regeln auf Daten basieren, die Regeln erstellen können, sondern auf ein einfacheres Regelsystem.

Wie auch immer, ich hoffe, dieses Beispiel zeigt, wie ein Regelsystem dazu beitragen kann, eine größere Anwendung zu erweitern.

Der größte Vorteil, den ich für Regel-Engines gesehen habe, ist, dass die Eigentümer von Geschäftsregeln die Geschäftsregeln implementieren können, anstatt die Programmierer zu belasten. Selbst wenn Sie einen agilen Prozess haben, in dem Sie ständig Feedback von Stakeholdern erhalten und schnelle Iterationen durchlaufen, wird dies immer noch nicht die Effizienz erreichen, die erreicht werden kann, wenn die Mitarbeiter, die die Geschäftsregeln erstellen, diese ebenfalls implementieren.

Außerdem können Sie den Wert beim Entfernen des Zyklus zum erneuten Kompilieren, erneuten Testen und erneuten Bereitstellen, der sich aus einer einfachen Regeländerung ergeben kann, nicht unterschätzen, wenn die Regeln in Code eingebettet sind. Es gibt oft mehrere Teams, die daran beteiligt sind, einem Build den Segen zu geben, und die Verwendung einer Rules Engine kann vieles davon unnötig machen.

Ich habe eine Regel-Engine für einen Client geschrieben. Der größte Gewinn war die Einbeziehung aller Beteiligten. Die Engine konnte eine Abfrage ausführen (oder wiedergeben) und erklären, was im Text geschah. Die Geschäftsleute konnten sich die Textbeschreibung ansehen und schnell auf Nuancen in Regeln, Ausnahmen und anderen Sonderfällen hinweisen. Sobald die Geschäftsseite involviert war, wurde die Validierung viel besser, weil es einfach war, ihre Beiträge zu erhalten. Darüber hinaus kann die Regelengine getrennt von anderen Teilen einer Anwendungscodebasis ausgeführt werden, sodass Sie sie anwendungsübergreifend verwenden können.

Der Nachteil ist, dass einige Programmierer nicht gerne zu viel lernen. Regel-Engines und die Regeln, die Sie in sie einfügen, sowie die Dinge, die sie implementieren, können etwas haarig sein. Obwohl ein gutes System leicht mit kranken und verdrehten logischen Netzen umgehen kann (oder oft unlogisch;), ist es nicht so einfach wie das Codieren einer Reihe von ifAnweisungen (unabhängig davon, was einige der einfältigen Regel-Engines tun). Die Regelengine bietet Ihnen die Werkzeuge, um mit Regelbeziehungen umzugehen, aber Sie müssen sich all das noch in Ihrem Kopf vorstellen können. Manchmal ist es wie im Film Brasilien zu leben . :) :)

Es hängt (wie alles andere auch) von Ihrer Anwendung ab. Für einige Anwendungen (normalerweise diejenigen, die sich nie ändern oder die Regeln sind am besten für Konstanten im wirklichen Leben, dh sie ändern sich in Äonen nicht merklich, zum Beispiel physikalische Eigenschaften und Formeln) ist es nicht sinnvoll, eine Regelengine zu verwenden, sondern nur führt zu zusätzlicher Komplexität und erfordert vom Entwickler größere Fähigkeiten.

Für andere Anwendungen ist es wirklich eine gute Idee. Nehmen wir zum Beispiel die Auftragsabwicklung (Bestellungen reichen von der Rechnungsstellung bis zur Abwicklung von Währungstransaktionen). Hin und wieder gibt es eine winzige Änderung eines relevanten Gesetzes oder Codes (im juristischen Sinne), nach der Sie eine neue Anforderung erfüllen müssen (zum Beispiel Umsatzsteuer) ein Klassiker). Anstatt zu versuchen, Ihre alte Anwendung in diese neue Situation zu zwingen, in der Sie plötzlich über die Umsatzsteuer nachdenken müssen, wo Sie es wie zuvor nicht getan haben, ist es einfacher, Ihren Regelsatz anzupassen, als sich in potenziell große Bereiche einzumischen Satz Ihres Codes.

Dann erfordert die nächste Änderung Ihrer lokalen Regierung die Meldung aller Verkäufe innerhalb eines bestimmten Kriteriums, anstatt dass Sie dies ebenfalls hinzufügen müssen. Am Ende erhalten Sie sehr komplexen Code, der sich als schwierig zu verwalten erweist, wenn Sie sich umdrehen und die Wirkung einer der Regeln rückgängig machen möchten, ohne alle anderen zu beeinflussen ...

Bisher haben alle die Regel-Engines sehr positiv bewertet, aber ich rate dem Leser, vorsichtig zu sein. Wenn ein Problem etwas komplizierter wird, stellen Sie möglicherweise plötzlich fest, dass eine gesamte Regelengine ungeeignet oder viel komplizierter als in einer leistungsfähigeren Sprache ist. Bei vielen Problemen können Regel-Engines Eigenschaften, die die Laufzeit und den Speicherbedarf bei der Bewertung der Bedingung erheblich verringern, nicht einfach erkennen. Es gibt relativ wenige Situationen, in denen ich eine Regelengine einem Abhängigkeitsinjektionsframework oder einer dynamischeren Programmiersprache vorziehen würde.

"Aber wie viele Apps haben wirklich so viele Änderungen?"

Ehrlich gesagt hat jede App, an der ich gearbeitet habe, ernsthafte Workflow- und / oder Logikänderungen vom Konzept bis weit nach der Bereitstellung durchlaufen. Dies ist der Hauptgrund für die "Wartungs" -Programmierung ...

Die Realität ist, dass man nicht an alles im Voraus denken kann, daher der Grund für agile Prozesse. Außerdem scheinen die BAs immer etwas Wichtiges zu verpassen, bis es beim Testen gefunden wird.

Rule Engines zwingen Sie dazu, Geschäftslogik wirklich von Präsentation und Speicherung zu trennen. Wenn Sie die richtige Engine verwenden, können Ihre BAs bei Bedarf Logik hinzufügen und entfernen. Wie Chris Marasti-Georg sagte, liegt die Verantwortung bei der BA. Darüber hinaus kann der BA genau das bekommen, wonach er fragt.

Eine Regelengine ist ein Gewinn für eine konfigurierbare Anwendung, bei der Sie keine benutzerdefinierten Builds durchführen müssen, wenn dies vermieden werden kann. Sie sind auch gut darin, große Regeln zu zentralisieren, und Algorithmen wie Rete sind effizient für den schnellen Abgleich mit großen Regelsätzen.

Viele gute Antworten, aber ich wollte ein paar Dinge hinzufügen:

1. Bei der Automatisierung einer Entscheidung von beliebiger Komplexität wird das Kritische schnell zu Ihrer Fähigkeit, die betreffende Logik zu verwalten, anstatt sie auszuführen. Eine Regelengine hilft dabei nicht weiter - Sie müssen über die Regelverwaltungsfunktionen nachdenken, über die ein Geschäftsregelverwaltungssystem verfügt. Die meisten kommerziellen und Open-Source-Regelengines haben sich zu Regelverwaltungssystemen mit Repositorys, Berichten zur Regelnutzung, Versionierung usw. entwickelt. Ein Repository von Regeln, das in kohärenten Regelsätzen strukturiert ist, die für Geschäftsentscheidungen orchestriert werden können, ist viel einfacher zu verwalten als beide Tausende von Codezeilen oder eine Regelsuppe.
2. Es gibt viele Möglichkeiten, einen deklarativen, regelbasierten Ansatz zu verwenden. Die Verwendung von Regeln zum Verwalten einer Benutzeroberfläche oder als Teil der Definition eines Prozesses kann sehr effektiv sein. Die wertvollste Verwendung eines Regelansatzes besteht jedoch darin, Geschäftsentscheidungen zu automatisieren und diese als lose gekoppelte Entscheidungsdienste bereitzustellen, die Eingaben entgegennehmen, Regeln ausführen und eine Antwort zurückgeben - eine Entscheidung. Dies sind Services, die Fragen zu anderen Services beantworten, z. B. "Ist dieser Kunde ein gutes Kreditrisiko?" Oder "Welchen Rabatt sollte ich diesem Kunden für diese Bestellung gewähren oder" Was ist derzeit der beste Cross-Selling für diesen Kunden? Diese Entscheidungsdienste können mithilfe eines Regelverwaltungssystems sehr effektiv erstellt werden und ermöglichen eine einfache Integration von Analysen im Laufe der Zeit, wovon viele Entscheidungen profitieren.

Ich sehe Regel-, Prozess- und Daten-Engines (auch bekannt als Datenbanken) als im Wesentlichen ähnlich an. Aus irgendeinem Grund sagen wir jedoch nie, dass das Blackboxing des Persistenz-Subsystems schlecht ist.

Zweitens ist aus meiner Sicht ein anämisches Modell nicht leicht in der Umsetzung von Verhaltensweisen, sondern leicht in Verhaltensweisen . Die eigentliche Methode, die ein verfügbares Verhalten in einem Domänenmodellobjekt beschreibt, muss nicht vom Objekt selbst ausgeführt werden.

Die größte Komplexität aus meiner Erfahrung mit Regel-Engines ist folgende:

1. Von OOP POV aus ist es ein echtes Problem, Regeln, die in einer deklarativen Sprache geschrieben wurden, umzugestalten und zu testen, während Sie Code umgestalten, der sie betrifft.
2. Oft sollten wir immer über die Ausführungsreihenfolge von Regeln nachdenken, die sich in ein Chaos verwandeln, wenn es viele davon gibt.
3. Einige geringfügige Änderungen können ein falsches Verhalten von Regeln auslösen, das zu Produktionsfehlern führt. In der Praxis ist es nicht immer möglich, alle Fälle mit Tests im Voraus abzudecken.
4. Regeln, die Objekte mutieren, die in anderen verwendet werden, erhöhen auch die Komplexität, was dazu führt, dass Entwickler sie in Stufen aufteilen.