Geschäftsregel

Eine fachliche Wenn-dann-Regel wie „Schäden über 100 000 Euro reguliert nur die Zentrale“. Oft steckt sie versteckt in verschachtelten if-Abfragen im Code. Eine Regelmaschine (Rule Engine) macht solche Regeln zu eigenständigen, deklarativen Einheiten, die sich einfacher ändern lassen, aber wie Code verwaltet und getestet werden müssen.

Das Problem

Geschäftsregeln sind „domänenspezifische Kausalzusammenhänge oder bedingte Handlungsanweisungen“ (Quelle - Effektive Softwarearchitekturen, S. 228). Beispiele aus dem Buch:

• Versicherung: Schäden über 100 000 Euro reguliert nur die Zentrale.
• Versicherung: Ist ein Topmanager des Konzerns beteiligt, bearbeiten nur Sachbearbeiter der Vertraulichkeitsstufe V1 den Fall.
• Finanzbehörde: Wer mehr als zweimal erst nach Erinnerung zahlt, bekommt 24 Monate keinen Aufschub.

Starkes These: Zu viele solcher Regeln stecken „fest zementiert“ in verschachtelten if-then-else-Konstrukten. Fachobjekte rufen sich gegenseitig auf, die Ablauflogik ist verteilt, Änderungen werden schwer (S. 229–230).

Regelmaschinen

Regeln werden als eigene Einheiten in einer Regelsprache beschrieben und von einer Regelmaschine ausgeführt (S. 230–231):

• Eine Regel besteht aus dem Wenn-Teil (Left-Hand-Side, LHS, Bedingungen) und dem Dann-Teil (Right-Hand-Side, RHS, Aktionen), etwa when Person.Age < 18 then Person.setCreditAllowed(false).
• Regeln sind deklarativ: Sie sagen, was gelten soll; das Wie erledigt die Maschine, genau wie bei SQL oder regulären Ausdrücken.
• Die Maschine arbeitet auf einem Working Memory mit Fakten, im Zyklus Match (alle erfüllbaren Regeln finden, Conflict Set) → Select (Reihenfolge bestimmen) → Act (Aktionen ausführen, was neue Fakten erzeugen kann). Optimierte Algorithmen dafür sind RETE und LEAPS.
• Die Wurzeln liegen in den Expertensystemen der KI der 1980er-Jahre.
• Bekanntes Open-Source-Produkt: JBoss Drools.

Erfolgreiche Einsätze: Routing von Nachrichten nach Inhalt, Tarif- und Preisberechnung bei Versicherungen, Callcenter-Abläufe, Steuerung von Batch-Verarbeitung (S. 233).

Wann eine Regelmaschine?

Dafür spricht (S. 233–234):

• Entscheidungen hängen an vielen verschachtelten Bedingungen.
• Die Regeln ändern sich oft.
• Man kann sie zusammen mit Fachleuten in Wenn-dann-Form aufschreiben.

Dagegen spricht:

• Entscheidungen lassen sich per Datenbankabfrage oder Berechnung treffen.
• Die Regeln ändern sich selten, oder es braucht nur ein, zwei if-Abfragen.
• Es kommt auf Millisekunden an.
• Regeln müssen auch auf dem Client laufen.
• Das System ist sauber nach Ports und Adaptern gebaut (Architekturstil).

Probleme:

• Entwickler imperativer Sprachen tun sich mit dem deklarativen Denken schwer. Deshalb klein anfangen und Regelsprachen nie für normale Programme missbrauchen.
• Die hohe Flexibilität ist ein Risiko: Wer im Produktivsystem schnell eine Regel im Texteditor ändert, gefährdet die Stabilität.
• Regeln müssen wie Code versioniert, getestet und verwaltet werden (S. 234).

Die zwei Beispiele im Buch

• M&M (Datenmigration): Das Team verzichtete auf eine kommerzielle Regelmaschine und auf eine eigene Regelsprache (mit Lex und Yacc), weil sie gegenüber Java nichts vereinfachten. Im Rückblick würde Starke Drools prüfen (S. 370, 375).
• MaMa (CRM-Kampagnen): Die Abläufe jeder Kampagne werden über Regeln in Drools gesteuert. Ein Rule Engine Wrapper kapselt die Maschine und nutzt vorbereitete Working-Memory-Sessions wieder, damit pro Datensatz nur noch Fakten eingefügt werden müssen (S. 402–403, arc42).

Für Geschäftsprozesse über längere Zeit gibt es zusätzlich Workflow- und BPM-Systeme mit BPMN 2.0 und DMN für Entscheidungstabellen (Kap. 7.7).

Verwandt

• Domain-Driven Design – wo Fachlogik im Modell wohnt
• Architekturstil – Ports und Adapter als Alternative
• arc42 – die Beispiele M&M und MaMa
• Wissensrepräsentation damals und heute – Regeln und Expertensysteme in der KI
• SQL – ebenfalls deklarativ