Fest codierte Preislogik: Warum eine Preisänderung 5 Tage dauert
In wettbewerbsintensiven Branchen wie Luftfahrt, E-Commerce und Fintech ist die Geschwindigkeit einer Entscheidung oft wichtiger als die Entscheidung selbst. Wenn ein Wettbewerber die Preise senkt oder ein neuer Risikofaktor auftaucht, bleiben nur wenige Stunden, um zu reagieren.
In vielen Unternehmensarchitekturen ist die Geschäftslogik – also die konkreten Regeln, die über Preise, Berechtigungen oder Risiken entscheiden – jedoch eng mit dem Anwendungscode verknüpft.
Dieses Architekturmuster erzeugt einen Engpass: Jede Anpassung eines Preismodells löst einen kompletten Softwareentwicklungszyklus aus. Eine Änderung, die Minuten dauern sollte, nimmt durch Entwicklung, Tests, Code-Reviews und Deployment-Pipelines am Ende Tage in Anspruch.
Diese Fallstudie analysiert, welche Auswirkungen die Entkopplung der Preislogik mithilfe einer Business Rules Engine (BRE) wie DecisionRules hat – am Beispiel einer funktionsfähigen Flugbuchungsanwendung als Referenzimplementierung.
In den Code eingebettete Logik
Beim klassischen Ansatz zur Umsetzung dynamischer Preisgestaltung wird die Bedingungslogik direkt in Backend-Services (z. B. Node.js oder Python) geschrieben. Bei einfachen Anwendungen funktioniert das, im großen Maßstab wird es jedoch unbeherrschbar.
Nehmen Sie eine typische Preisfunktion: Die Logik ist in der Regel über mehrere Dateien mit verschachtelten Bedingungen verstreut.
Die „fest codierte“ Implementierung
Das folgende vereinfachte Beispiel zeigt, wie Preisregeln in einem Node.js- oder Python-Service typischerweise aussehen:
// ⚠️ THE ANTI-PATTERN: Business logic coupled with application code
function calculateTicketFare(origin, destination, cabinClass, type, adults) {
let baseFare = 0;
// Logic explicitly defined in code
if (origin === "HND" && destination === "IST") {
baseFare = cabinClass === "Economy" ? 800 :
cabinClass === "Business" ? 2000 : 3500;
} else if (origin === "ATL" && destination === "DXB") {
// ... logic repeats for hundreds of routes
baseFare = 900;
}
// Hard-coded multipliers require redeployment to change
if (type === "Round") baseFare *= 1.8;
// Complex calculation hidden in the backend
return (adults * baseFare) + (children * baseFare * 0.75);
}Die operativen Kosten
Dieser Ansatz verursacht erhebliche Reibungsverluste:
- Hohe Latenz: Um auf eine Marktveränderung zu reagieren, muss ein Entwickler den Code ändern, Unit-Tests anpassen, das Code-Review bestehen und die Änderung deployen.
- Ständiger Testaufwand: Schon eine kleine Änderung an einer Variablen (z. B. den Multiplikator für Hin- und Rückflüge von 1.8 auf 1.7 senken) erfordert die Anpassung von Regressionstests und erhöht das Risiko, neue Fehler einzuschleusen.
- Undurchsichtige Logik: Fachliche Stakeholder (Revenue Manager) können die Logik nicht direkt überprüfen und sind darauf angewiesen, dass Entwickler ihnen den Code erklären.
Die Lösung: Entkopplung der Logik über eine API
Die alternative Architektur folgt dem Prinzip der Separation of Concerns (Trennung der Zuständigkeiten). Die Anwendung steuert den Workflow (UI, Datenbank, Orchestrierung), während eine dedizierte Business Rules Engine (wie DecisionRules) die Logik übernimmt. Die Preisfunktion wird so von einer Berechnung zu einer I/O-Operation: Die Anwendung übermittelt den Kontext (Reisedaten), und die Engine liefert die Entscheidung (Preis) zurück.
Die Flugbuchungs-Referenz-App
Um die Wirkung dieser Architektur zu messen, haben wir eine voll funktionsfähige Beispielanwendung für Flugbuchungen untersucht. Das System verarbeitet einen Ablauf in drei Schritten:
- Reiseauswahl: Abflugort, Zielort, Beförderungsklasse.
- Zusatzleistungen: Sitzplatzwahl, Gepäck, Versicherung.
- Preisberechnung: Endgültige Kalkulation.
Durch die Migration der Logik nach DecisionRules ließ sich der Anwendungscode deutlich reduzieren, und die Kontrolle über die Preisparameter ging an die Fachanwender über.
Umsetzung: Vom Code zur Konfiguration
In der Flugbuchungs-Referenzanwendung abstrahieren wir die Variablen, um „Magic Numbers“ im Code zu vermeiden. Statt Werte fest einzubetten, definieren wir in der Engine spezifische Regelvariablen, die Fachanwender selbst verwalten können.
1. Das Input-/Output-Modell definieren
Der erste Schritt besteht darin, die Variablen zu abstrahieren. In DecisionRules definieren wir eine JSON-Struktur, die die Regel erwartet. Sie dient als Vertrag zwischen Anwendung und Engine.
- Input-Modell: origin, destination, class, passengers, ancillaryServices
- Output-Modell: baseFare, taxes, totalPrice, breakdown
2. Die Decision Table aufbauen
Statt in If-else-Anweisungen wird die Logik in einer Decision Table abgebildet. Die Engine gleicht die Eingabezeilen (Bedingungen) ab, um das Ergebnis (Resultate) zu bestimmen.
Wichtige Geschäftsvariablen (in der Engine konfiguriert):
- roundTripMultiplier: 1.8
- seatPrice: 35
- childFarePercentage: 0.85
- additionalLuggagePricePerBag: 55
- airportLoungePricePerAdult: 60
Steigt der Preis für einen Sitzplatz, aktualisiert ein Anwender die Variable seatPrice, und die Änderung greift sofort in allen Regeln – ganz ohne Code-Deployment.
Kernfunktion: komplexe Funktionen
DecisionRules unterstützt fortgeschrittene Funktionen für dynamische Berechnungen. So erfordert etwa die Berechnung des Preises für die ausgewählten Sitzplätze keinen externen Code, sondern erfolgt direkt in der Ergebnisspalte der Regel mithilfe von Array-Funktionen:
// ✅ THE MODERN PATTERN: Delegating logic to the engine
const response = await fetch(
`https://api.decisionrules.io/rule/solve/flight-tickets-pricing`,
{
method: 'POST',
headers: {
'Authorization': `Bearer ${process.env.DECISION_RULES_KEY}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({
data: {
tripDetails: {
origin: "HND",
destination: "IST",
classOfService: "Business",
passengers: { adults: 2, children: 1 }
},
ancillaryServices: {
loungeAccess: true,
extraBags: 2
}
}
})
}
);
const pricing = (await response.json())[0];
// Result: pricing.grandTotalPrice = 5450Technischer Deep Dive: Performance & Architektur
Bei der Bewertung einer BRE für den Unternehmenseinsatz sind drei nicht-funktionale Anforderungen entscheidend: Latenz, Versionierung und Sicherheit.
0Die Auslagerung der Logik bringt einen zusätzlichen Netzwerk-Hop mit sich, effiziente BREs gleichen das jedoch aus. Die DecisionRules Solver API führt komplexe Decision Tables in der Regel in Millisekunden aus.
- Caching-Strategie: Die Engine speichert Regeldefinitionen im Cache. Wird dieselbe Regel wiederholt aufgerufen, muss die Engine die Regelstruktur nicht erneut aus der Datenbank laden, was die Verarbeitungszeit erheblich verkürzt.
- Regionale Edge-Standorte: API-Aufrufe lassen sich an das nächstgelegene Rechenzentrum leiten, um die Netzwerklatenz zu minimieren.
Versionierung und Rollbacks
In einer fest codierten Umgebung bedeutet die Korrektur eines Preisfehlers, einen Git-Commit rückgängig zu machen und die Anwendung erneut zu deployen.
In DecisionRules erzeugt jedes Speichern eine neue unveränderliche Version.
- Über die API können Sie für mehr Stabilität eine bestimmte Version (z. B. v1.2) fest vorgeben oder für mehr Agilität stets die neueste Version verwenden.
- Bleibt eine neue Preisstrategie hinter den Erwartungen zurück, kann der Fachbereich über die Benutzeroberfläche sofort und ohne Ausfallzeit zur vorherigen Version zurückkehren.
Audit-Trails und Sicherheit
Finanz- und Preissysteme erfordern eine lückenlose Nachvollziehbarkeit.
- RBAC (rollenbasierte Zugriffskontrolle): Granulare Berechtigungen stellen sicher, dass nur autorisierte Personen (z. B. Senior Revenue Manager) Änderungen an produktiven Regeln veröffentlichen können.
- Event Logs: Jede Änderung wird mit Zeitstempel, Benutzer-ID und einem Diff der geänderten Werte protokolliert. So entsteht ein vollständiger Compliance-Nachweis, der mit herkömmlichen Code-Repositories nur schwer zu erreichen ist.
Vergleichsanalyse
Die folgende Tabelle vergleicht die operativen Kennzahlen bei der Pflege von Preislogik im Code mit denen beim Einsatz einer dedizierten Engine.
| Kennzahl | Fest codierte Architektur | Business Rules Engine |
|---|---|---|
| Änderungsablauf | Code → Unit-Test → QA → Deployment | Wert bearbeiten → Speichern → Veröffentlichen |
| Time-to-Market | 3-5 Tage | < 65 Sekunden |
| Testumfang | Vollständige Regressionstests erforderlich | Isolierte Regeltests im Test Bench |
| Wartungskosten | Hoch (technische Schulden) | Niedrig (Konfiguration) |
| Kennzahl | Fest codierte Architektur | Business Rules Engine |
| Änderungsablauf | Code → Unit-Test → QA → Deployment | Wert bearbeiten → Speichern → Veröffentlichen |
Ein Szenario aus der Praxis
Um den Geschwindigkeitsunterschied zu veranschaulichen, nehmen wir an, ein Wettbewerber senkt die Business-Class-Tarife auf der Strecke HND → IST, und das Pricing-Team muss sofort nachziehen.
Ablauf mit einer Business Rules Engine:
- Der Revenue Manager öffnet die Decision Table: 10 Sek.
- Er sucht die Zeile für HND → IST in der Business Class: 20 Sek.
- Er aktualisiert den Preis ($2000 → $1700): 30 Sek.
- Er klickt auf „Publish“: 5 Sek.
- Gesamtdauer: 65 Sekunden
Fazit
Geschäftslogik fest zu codieren, ist nur bei statischen, unveränderlichen Regeln ein tragfähiger Ansatz. Bei dynamischen Systemen wie Preisgestaltung, Betrugserkennung oder Eignungsbewertung wird „Logic as Code“ zur Belastung, die die Agilität des Unternehmens ausbremst.
Mit „Logic as Configuration“ über ein Tool wie DecisionRules erreichen Unternehmen:
- Agilität: Reaktion auf Marktveränderungen in Echtzeit.
- Transparenz: Die Logik ist für die Verantwortlichen im Fachbereich sichtbar und nachvollziehbar.
- Effizienz: Entwickler werden von Wartungsaufgaben entlastet und können sich auf die Entwicklung neuer Funktionen konzentrieren.
Die Flugbuchungs-Fallstudie zeigt: Komplexe Preisgestaltung gehört nicht in die Codebasis, sondern in ein System, das für die Beherrschung von Komplexität entwickelt wurde.
Über den Autor: Lukas Martincek ist Fullstack-Entwickler bei DecisionRules und verfügt über mehr als 4 Jahre Erfahrung in der Full-Stack-Webentwicklung. Derzeit ist er auf die Integration von Large Language Models (LLMs) in Business Rules Engines spezialisiert, um die Regelerstellung, das Schreiben von Ausdrücken und die Dokumentationssuche zu automatisieren.
Lukas Martincek
Full Stack Engineer at DecisionRules
Lukáš Martinček is a Full Stack Engineer at DecisionRules. He develops features for the DecisionRules application and its supporting services, working across Angular, Node.js, APIs, and system integrations.