Wann sollten Sie KEINE Rules Engine verwenden? [geschlossen]

Ich habe eine ziemlich anständige Liste der Vorteile der Verwendung einer Regelengine sowie einige Gründe für deren Verwendung. Ich benötige eine Liste der Gründe, warum Sie eine Regelengine NICHT verwenden sollten

Das Beste, was ich bisher habe, ist Folgendes:

Regel-Engines sind weder für Workflow- oder Prozessausführungen gedacht, noch sind Workflow-Engines oder Prozessmanagement-Tools für die Ausführung von Regeln konzipiert.

Gibt es noch andere wichtige Gründe, warum Sie sie nicht verwenden sollten?

Ich werde sehr nervös, wenn ich sehe, dass Leute sehr große Regelsätze verwenden (z. B. in der Größenordnung von Tausenden von Regeln in einem einzigen Regelsatz). Dies passiert häufig, wenn die Regelengine ein Singleton ist, der im Zentrum des Unternehmens sitzt, in der Hoffnung, dass die Regeln trocken bleiben für viele Apps zugänglich werden, für die sie erforderlich sind. Ich würde jedem trotzen, mir zu sagen, dass eine Rete-Regel-Engine mit so vielen Regeln gut verstanden wird. Mir sind keine Tools bekannt, mit denen überprüft werden kann, ob keine Konflikte bestehen.

Ich denke, Partitionierungsregelsätze, um sie klein zu halten, sind eine bessere Option. Aspekte können eine Möglichkeit sein, einen gemeinsamen Regelsatz für viele Objekte zu verwenden.

Ich bevorzuge, wo immer möglich, einen einfacheren, datengesteuerteren Ansatz.

Ich werde 2 Beispiele aus persönlicher Erfahrung nennen, bei denen die Verwendung einer Rules Engine eine schlechte Idee war. Vielleicht hilft das: -

1. Bei einem früheren Projekt habe ich festgestellt, dass die Regeldateien (das Projekt verwendete Drools) viel Java-Code enthielten, einschließlich Schleifen, Funktionen usw. Es handelte sich im Wesentlichen um Java-Dateien, die sich als Regeldatei tarnten. Als ich den Architekten nach seiner Begründung für das Design fragte, wurde mir gesagt, dass die "Regeln niemals von Geschäftsanwendern eingehalten werden sollten".

Lektion : Sie werden aus einem bestimmten Grund als "Geschäftsregeln" bezeichnet. Verwenden Sie keine Regeln, wenn Sie kein System entwerfen können, das von Geschäftsbenutzern leicht gewartet / verstanden werden kann.

2. Ein anderer Fall; Das Projekt verwendete Regeln, weil Anforderungen schlecht definiert / verstanden und häufig geändert wurden. Die Lösung des Entwicklungsteams bestand darin, Regeln ausgiebig zu verwenden, um häufige Codebereitstellungen zu vermeiden.

Lektion : Die Anforderungen ändern sich in der Regel während der ersten Release-Änderungen erheblich und rechtfertigen nicht die Verwendung von Regeln. Verwenden Sie Regeln, wenn sich Ihr Unternehmen häufig ändert (keine Anforderungen). Beispiel: - Eine Software, die Ihre Steuern verwaltet, ändert sich jedes Jahr, wenn sich die Steuergesetze ändern und die Verwendung von Regeln eine hervorragende Idee ist. Release 1.0 einer Web-App ändert sich häufig, wenn Benutzer neue Anforderungen identifizieren, sich jedoch im Laufe der Zeit stabilisieren. Verwenden Sie keine Regeln als Alternative zur Codebereitstellung. .

Ich bin ein großer Fan von Business Rules Engines, da es Ihnen helfen kann, Ihr Leben als Programmierer viel einfacher zu gestalten. Eine der ersten Erfahrungen, die ich bei der Arbeit an einem Data Warehouse-Projekt gemacht habe, war das Auffinden gespeicherter Prozeduren mit komplizierten CASE-Strukturen, die sich über ganze Seiten erstrecken. Das Debuggen war ein Albtraum, da es sehr schwierig war, die in so langen CASE-Strukturen angewandte Logik zu verstehen und festzustellen, ob sich eine Regel auf Seite 1 des Codes mit einer anderen auf Seite 5 überschneidet. Insgesamt hatten wir mehr als 300 solcher Regeln in den Code eingebettet.

Als wir eine neue Entwicklungsanforderung für etwas namens Accounting Destination erhalten haben, bei dem mehr als 3000 Regeln behandelt wurden, wusste ich, dass sich etwas ändern musste. Damals habe ich an einem Prototyp gearbeitet, der später das übergeordnete Element einer benutzerdefinierten Geschäftsregel-Engine wurde, die alle SQL-Standardoperatoren verarbeiten kann. Zunächst haben wir Excel als Authoring-Tool verwendet und später eine ASP.net-Anwendung erstellt, mit der die Geschäftsbenutzer ihre eigenen Geschäftsregeln definieren können, ohne Code schreiben zu müssen. Jetzt funktioniert das System mit sehr wenigen Fehlern einwandfrei und enthält über 7000 Regeln für die Berechnung dieses Abrechnungsziels. Ich denke nicht, dass ein solches Szenario nur durch Hardcodierung möglich gewesen wäre.

Dennoch gibt es Grenzen für einen solchen Ansatz:

• Sie benötigen fähige Geschäftsanwender, die das Unternehmensgeschäft hervorragend verstehen.
• Das Durchsuchen des gesamten Systems (in unserem Fall eines Data Warehouse) ist mit einem erheblichen Arbeitsaufwand verbunden, um alle fest codierten Bedingungen zu ermitteln, die sinnvoll sind, um in Regeln übersetzt zu werden, die von einer Business Rule Engine verarbeitet werden. Wir mussten auch darauf achten, dass diese anfänglichen Vorlagen für Geschäftsbenutzer vollständig verständlich sind.
• Für die Erstellung von Regeln muss eine Anwendung verwendet werden, in der Algorithmen zur Erkennung überlappender Geschäftsregeln implementiert sind. Andernfalls kommt es zu einem großen Durcheinander, bei dem niemand mehr versteht, welche Ergebnisse sie erzielen. Wenn Sie einen Fehler in einer generischen Komponente wie einer Custom Business Rule Engine haben, kann es sehr schwierig sein, Fehler zu beheben und umfangreiche Tests durchzuführen, um sicherzustellen, dass die zuvor funktionierenden Dinge jetzt auch funktionieren.

Weitere Details zu diesem Thema finden Sie in einem Beitrag, den ich geschrieben habe: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

Insgesamt besteht der größte Vorteil der Verwendung von Business Rule Engines darin, dass die Benutzer die Kontrolle über die Definitionen und das Authoring von Business Rules zurückerhalten können, ohne jedes Mal zur IT-Abteilung gehen zu müssen, wenn sie etwas ändern müssen. Dies reduziert auch die Arbeitsbelastung der IT-Entwicklungsteams, die sich nun darauf konzentrieren können, Dinge mit mehr Mehrwert zu erstellen.

Prost,

Nicolae

Der einzige Punkt, den ich als "zweischneidiges Schwert" bemerkt habe, ist:

die Logik in die Hände von nicht technischem Personal legen

Ich habe diese Arbeit großartig gesehen, wenn Sie ein oder zwei multidisziplinäre Genies auf der nicht-technischen Seite haben, aber ich habe auch den Mangel an Technik gesehen, der zu Blähungen, mehr Fehlern und im Allgemeinen dem 4-fachen der Entwicklungs- / Wartungskosten führt.

Daher müssen Sie Ihre Benutzerbasis ernsthaft berücksichtigen.

Ich fand den Artikel von Alex Papadimoulis ziemlich aufschlussreich: http://thedailywtf.com/articles/soft_coding.aspx

Es ist nicht umfassend, aber er hat einige gute Punkte.

Toller Artikel darüber, wann man keine Regel-Engine verwendet ... (sowie wann man eine verwendet) ....

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

Eine andere Option ist, wenn Sie einen linearen Regelsatz haben, der nur einmal in einer beliebigen Reihenfolge angewendet wird, um ein Ergebnis zu erzielen, eine groovige Oberfläche zu erstellen und die Entwickler diese neuen Regeln schreiben und bereitstellen zu lassen. Der Vorteil ist, dass es unglaublich schnell ist, da Sie normalerweise die Sitzung im Ruhezustand ODER die JDBC-Sitzung sowie alle Parameter übergeben würden, sodass Sie auf effiziente Weise auf alle Daten Ihrer Apps zugreifen können. Mit einer Faktenliste kann es eine Menge Looping / Matching geben, die das System wirklich verlangsamen können ..... Es ist eine andere Möglichkeit, eine Regelengine zu vermeiden und dynamisch bereitgestellt zu werden (ja, unsere groovigen Regeln wurden in a bereitgestellt Datenbank und wir hatten keine Rekursion .... es hat entweder die Regel erfüllt oder es hat nicht). Es ist nur eine weitere Option ..... oh und ein weiterer Vorteil ist, dass die Syntax von Regeln für eingehende Entwickler nicht gelernt wird.

Es hängt wirklich von Ihrem Kontext ab. Die Regelengine hat ihren Platz und das oben Genannte ist nur eine weitere Option, wenn Sie Regeln für ein Projekt haben, die Sie möglicherweise dynamisch für sehr vereinfachte Situationen bereitstellen möchten, für die keine Regelengine erforderlich ist.

Verwenden Sie grundsätzlich KEINE Regelengine, wenn Sie einen einfachen Regelsatz haben und stattdessen eine groovige Oberfläche haben können ..... genauso dynamisch bereitstellbar und neue Entwickler, die Ihrem Team beitreten, können sie schneller lernen als die Sprache der Sabber. (Aber das ist meine Meinung)

Nach meiner Erfahrung funktionieren Regel-Engines am besten, wenn Folgendes zutrifft:

1. Gut definierte Doktrin für Ihre Problemdomäne
2. Hochwertige (vorzugsweise automatisierte) Daten, mit denen Sie die meisten Ihrer Eingaben steuern können
3. Zugang zu Fachexperten
4. Softwareentwickler mit Erfahrung in der Erstellung von Expertensystemen

Wenn eines dieser vier Merkmale fehlt, funktioniert möglicherweise immer noch eine Regelengine für Sie, aber jedes Mal, wenn ich es mit nur einem fehlenden versucht habe, bin ich auf Probleme gestoßen.

Das ist sicherlich ein guter Anfang. Die andere Sache mit Regel-Engines ist, dass einige Dinge gut verstanden, deterministisch und unkompliziert sind. Lohn- und Gehaltsabrechnung ist (oder war früher) so. Sie könnten es als Regeln ausdrücken, die von einer Regelengine aufgelöst würden, aber Sie könnten dieselben Regeln wie eine ziemlich einfache Wertetabelle ausdrücken.

Workflow-Engines sind also gut, wenn Sie einen längerfristigen Prozess ausdrücken, der persistente Daten enthält. Regel-Engines können etwas Ähnliches tun, aber Sie müssen viel mehr Komplexität tun.

Regel-Engines sind gut, wenn Sie über komplizierte Wissensdatenbanken verfügen und eine Suche benötigen. Regel-Engines können komplizierte Probleme lösen und können schnell an sich ändernde Situationen angepasst werden, die Basisimplementierung ist jedoch sehr komplex.

Viele Entscheidungsalgorithmen sind einfach genug, um als einfaches tabellengesteuertes Programm ausgedrückt zu werden, ohne die Komplexität, die eine echte Regelengine impliziert.

Ich würde Business Rules Engines wie Drools als Open Source oder Commercial Rules Engine wie LiveRules dringend empfehlen.

• Wenn Sie viele Geschäftsrichtlinien haben, die volatiler Natur sind, ist es sehr schwierig, diesen Teil des Kerntechnologiecodes beizubehalten.
• Die Regelengine bietet eine große Flexibilität des Frameworks und ist einfach zu ändern und bereitzustellen.
• Regel-Engines dürfen nicht überall verwendet werden, sondern müssen verwendet werden, wenn Sie viele Richtlinien haben, bei denen Änderungen regelmäßig unvermeidlich sind.

Ich verstehe einige Punkte nicht wirklich wie:
a) Geschäftsleute müssen das Geschäft sehr gut verstehen, oder;
b) Meinungsverschiedenheiten über Geschäftsleute müssen die Regel nicht kennen.

Für mich als Menschen, die nur BRE berühren, ist der Vorteil von BRE so genannt, dass sich das System an geschäftliche Veränderungen anpassen kann, daher konzentriert es sich auf die Anpassung an Veränderungen.
Ist es wichtig, ob sich die zum Zeitpunkt x festgelegte Regel von der zum Zeitpunkt y festgelegten Regel unterscheidet, weil:
a) Geschäftsleute das Geschäft nicht verstehen oder;
b) Geschäftsleute verstehen Regeln nicht?