web-dev-qa-db-de.com

Wann sollten Sie KEINE Rules Engine verwenden?

Ich habe eine ziemlich anständige Liste der Vorteile einer Rules Engine sowie einige Gründe, sie zu verwenden. Ich benötige eine Liste der Gründe, warum Sie KEINE Rules Engine verwenden sollten

Das Beste, was ich bisher habe, ist folgendes:

Regel-Engines sind nicht für die Ausführung von Workflows oder Prozessen gedacht, und Workflow-Engines oder Prozessmanagement-Tools sind nicht für die Ausführung von Regeln konzipiert.

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

106
BlackTigerX

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 einzelnen Regelsatz). Dies ist häufig der Fall, wenn die Regelengine ein Singleton im Zentrum des Unternehmens ist, in der Hoffnung, dass das Beibehalten von Regeln TROCKEN sie für viele Apps zugänglich macht, die dies erfordern Sie. Ich würde mich jedem widersetzen, 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 Konflikte bestehen.

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

Ich bevorzuge einen einfacheren, datenorientierteren Ansatz, wo immer dies möglich ist.

32
duffymo

Ich werde zwei Beispiele aus eigener Erfahrung nennen, bei denen die Verwendung einer Regel-Engine eine schlechte Idee war. Vielleicht hilft das:

  1. Bei einem früheren Projekt habe ich festgestellt, dass die Regeldateien (das von Drools verwendete Projekt) viel Java Code enthielten, einschließlich Schleifen, Funktionen usw. Es handelte sich im Wesentlichen um Java Dateien, die sich als Regeln tarnen Datei. 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 einfach gewartet/verstanden werden kann.

  1. Ein anderer Fall; Das Projekt verwendete Regeln, da die Anforderungen häufig schlecht definiert/verstanden und geändert wurden. Die Lösung des Entwicklungsteams bestand darin, Regeln weitgehend zu verwenden, um häufige Code-Bereitstellungen zu vermeiden.

Lektion: Anforderungen ändern sich bei Änderungen der Erstveröffentlichung häufig und rechtfertigen nicht die Verwendung von Regeln. Verwenden Sie Regeln, wenn sich Ihr Unternehmen häufig ändert (keine Anforderungen). ZB: - Eine Software, die Ihre Steuern berechnet, ändert sich jedes Jahr, da 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 erkennen, wird sich jedoch im Laufe der Zeit stabilisieren. Verwenden Sie keine Regeln als Alternative zur Codebereitstellung. Um die Umstellung zu erleichtern, müssen Sie

143
VDev

Ich bin ein großer Fan von Business Rules Engines, da dies Ihnen das Leben als Programmierer erheblich erleichtern kann. Eine der ersten Erfahrungen, die ich bei der Arbeit an einem Data Warehouse-Projekt gemacht habe, bestand darin, gespeicherte Prozeduren zu finden, die komplizierte CASE-Strukturen enthalten, die sich über ganze Seiten erstrecken. Das Debuggen war ein Albtraum, da es sehr schwierig war, die in solch 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 mehr als 300 solcher Regeln im Code eingebettet.

Als wir eine neue Entwicklungsanforderung für das Buchhaltungsziel 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 Custom Business Rule-Engine wurde, die alle SQL-Standardoperatoren verarbeiten kann. Anfänglich 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 einwandfrei mit sehr wenigen Fehlern und enthält über 7000 Regeln zur Berechnung dieses Abrechnungsziels. Ich glaube nicht, dass ein solches Szenario nur durch Hardcodierung möglich gewesen wäre. Und die Benutzer sind ziemlich froh, dass sie ihre eigenen Regeln definieren können, ohne dass die IT zu ihrem Engpass wird.

Trotzdem sind solchen Ansätzen Grenzen gesetzt:

  • Sie benötigen fähige Geschäftsanwender, die ein ausgezeichnetes Verständnis für das Geschäft des Unternehmens haben.
  • Das Durchsuchen des gesamten Systems (in unserem Fall eines Data Warehouse) ist sehr aufwändig, um alle fest codierten Bedingungen zu ermitteln, die sinnvoll sind, um sie in Regeln zu übersetzen, die von einer Business Rule Engine verarbeitet werden. Wir mussten auch gut darauf achten, dass diese anfänglichen Vorlagen für Geschäftsanwender vollständig verständlich sind.
  • Sie benötigen eine Anwendung zum Erstellen von Regeln, in der Algorithmen zum Erkennen überlappender Geschäftsregeln implementiert sind. Andernfalls kommt es zu einem großen Durcheinander, bei dem niemand mehr versteht, welche Ergebnisse erzielt werden. 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 Funktionen auch jetzt 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 der Geschäftsregeln wiedererlangen können, ohne dass sie sich jedes Mal an die IT-Abteilung wenden müssen, wenn sie etwas ändern müssen. Dies reduziert auch die Arbeitsbelastung der IT-Entwicklungsteams, die sich nun auf das Erstellen von Produkten mit mehr Mehrwert konzentrieren können.

Prost,

Nicolae

18
Nicolae Guse

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

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

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 gesehen, dass die mangelnde Technik zu Aufblähungen, mehr Fehlern und im Allgemeinen zu vierfachen Entwicklungs-/Wartungskosten führt.

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

17
Robert Gould

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.

11
Smashery

Toller Artikel darüber, wann man keine Rules Engine verwenden sollte ... (und wann man eine verwenden sollte) ....

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

Eine andere Option ist, wenn Sie über einen linearen Satz von Regeln verfügen, die nur einmal in einer beliebigen Reihenfolge angewendet werden, um ein Ergebnis zu erzielen, eine leistungsstarke Schnittstelle zu erstellen und die Entwickler diese neuen Regeln schreiben und bereitstellen zu lassen. Der Vorteil ist, dass es unglaublich schnell ist, denn normalerweise würden Sie die Ruhezustandssitzung OR jdbc-Sitzung sowie alle Parameter übergeben, damit Sie auf alle Ihre Apps-Daten zugreifen können, aber auf effiziente Weise Es kann eine Menge Schleifen/Übereinstimmungen geben, die das System wirklich verlangsamen können. Dies ist eine weitere Möglichkeit, eine Regel-Engine zu vermeiden und sich dynamisch implementieren zu lassen (ja, unsere starken Regeln wurden in einer Datenbank implementiert und Wir hatten keine Rekursion .... es hat entweder die Regel erfüllt oder nicht). Es ist nur eine weitere Option ..... Oh, und ein weiterer Vorteil ist, dass eingehende Entwickler die Regelsyntax nicht lernen aber das ist sehr nah an Java, also ist die Lernkurve viel besser.

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

Verwenden Sie grundsätzlich KEINE Regelengine, wenn Sie über einen einfachen Regelsatz verfügen und stattdessen über eine leistungsstarke Benutzeroberfläche verfügen ..... Ebenso dynamisch einsetzbar und neue Entwickler, die Ihrem Team beitreten, können dies schneller erlernen als die Programmiersprache Drools (aber das ist meiner Meinung nach).

10
Dean Hiller

Nach meiner Erfahrung funktionieren Regelmodule am besten, wenn Folgendes zutrifft:

  1. Gut definierte doctrine für Ihre Problemdomain
  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 eine dieser vier Eigenschaften fehlt, finden Sie möglicherweise immer noch eine Regel-Engine, die für Sie funktioniert. Aber jedes Mal, wenn ich es mit einer fehlenden probiert habe, bin ich auf Probleme gestoßen.

7
DaveParillo

Das ist sicher ein guter Anfang. Die andere Sache mit Regelmaschinen ist, dass einige Dinge gut verstanden, deterministisch und direkt sind. Einbehaltung der Lohn- und Gehaltsabrechnung ist (oder ist) so. Sie könnten es als Regeln ausdrücken, die von einer Regelengine aufgelöst würden, aber Sie könnten die gleichen Regeln ausdrücken wie eine ziemlich einfache Wertetabelle.

Workflow-Engines eignen sich daher gut, wenn Sie einen längerfristigen Prozess mit beständigen Daten ausdrücken. Regel-Engines können etwas Ähnliches tun, aber Sie müssen eine Menge zusätzlicher 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 schnell an sich ändernde Situationen angepasst werden. Die Basisimplementierung ist jedoch sehr komplex.

Viele Entscheidungsalgorithmen sind einfach genug, um sich als einfaches tabellengesteuertes Programm auszudrücken, ohne die Komplexität einer echten Regel-Engine.

1
Charlie Martin

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

Für mich als Menschen, die nur BRE berühren, ist der Nutzen 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, wenn sich die zum Zeitpunkt x eingerichtete Regel von der zum Zeitpunkt y eingerichteten Regel unterscheidet, weil:
a) Geschäftsleute verstehen das Geschäft nicht oder;
b) Geschäftsleute verstehen Regeln nicht?

0
x w

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

  • Wenn Sie eine Vielzahl von Unternehmensrichtlinien haben, die von Natur aus volatil sind, ist es sehr schwierig, diesen Teil des Kerntechnologiecodes beizubehalten.
  • Die Regel-Engine bietet eine große Flexibilität des Frameworks und ist leicht zu ändern und bereitzustellen.
  • Regel-Engines dürfen nicht überall verwendet werden, sondern müssen verwendet werden, wenn viele Richtlinien vorhanden sind, bei denen Änderungen regelmäßig unumgänglich sind.
0
muruga