Domain-Driven Design in der Praxis: Der RFU Case
Wie wir durch tiefes Domänenverständnis 80% Automatisierung erreicht haben.
Der RFU Case ist ein perfektes Beispiel dafür, wie Domain-Driven Design in der Praxis funktioniert. Anstatt mit einer vorgefertigten Lösung zu starten, haben wir uns intensiv mit den Geschäftsprozessen unseres Kunden aus dem Bankendienstleistungssektor auseinandergesetzt. Das Ergebnis: Eine AI-Lösung, die nicht nur funktioniert, sondern die Sprache der Domäne spricht und 80% der manuellen Arbeit automatisiert – mit einem Break-even von nur 1,5 Monaten.
Es gibt zwei Wege, AI-Systeme zu bauen: Man kann eine generische Lösung nehmen und versuchen, sie anzupassen. Oder man kann mit der Domäne beginnen und die Technologie drumherum bauen.
Wir wählen immer den zweiten Weg.
Der Fehler mit dem Generic Hammer
Viele AI-Projekte starten mit der Technologie: "Wir nehmen ein LLM, fine-tunen es ein bisschen, und fertig." Das Problem: Diese Lösung kennt die Geschäftsprozesse nicht. Sie versteht die Fachsprache nicht. Sie weiß nicht, welche Validierungen wichtig sind und welche Fehler kritisch.
Das Resultat sind Systeme, die in 80% der Fälle funktionieren – aber genau die 20% Sonderfälle nicht abdecken, die im Geschäftsalltag kritisch sind.
Was Domain-Driven Design wirklich bedeutet
Domain-Driven Design (DDD) ist keine Methodik, die man "mal eben anwendet". Es ist eine Philosophie, die das Verständnis der Geschäftsdomäne in den Mittelpunkt stellt.
Konkret bedeutet das:
1. Mit dem Geschäft beginnen, nicht mit der Technologie
Bevor wir über Modelle, Architekturen oder Frameworks sprechen, fragen wir: Welches Problem lösen wir? Wie funktioniert der aktuelle Prozess? Was sind die kritischen Anforderungen?
2. Die Sprache der Domäne sprechen
In der Finanzwelt gibt es "KPIs", "Risk Ratings", "Compliance-Kriterien". Diese Begriffe sind nicht austauschbar. Die AI muss dieselbe Sprache sprechen wie die Experten.
3. Das Geschäft modellieren, nicht nur die Daten
Es geht nicht nur darum, Dokumente zu verarbeiten. Es geht um Geschäftsregeln, Validierungen, Prozesse, Abhängigkeiten.
4. Mit Experten arbeiten, nicht gegen sie
Die besten Lösungen entstehen, wenn Technologie-Experten und Domänen-Experten eng zusammenarbeiten.
Der RFU Case: 500+ Seiten, 80% Automatisierung
Unser Kunde im Bankendienstleistungssektor stand vor einer massiven Herausforderung: Analysten mussten täglich hunderte Seiten an Jahresberichten manuell durchforsten, um quantitative und qualitative KPIs zu extrahieren.
Die naive Lösung: Ein LLM nehmen, Dokumente reinwerfen, KPIs extrahieren lassen.
Das Problem: Welche KPIs sind relevant? Wie validiert man die Extraktion? Wie geht man mit widersprüchlichen Informationen um? Was passiert bei Sonderfällen?
Unser Ansatz:
- Domänenanalyse: Wir haben Wochen damit verbracht, den Prozess zu verstehen. Welche KPIs gibt es? Wie werden sie definiert? Was sind typische Fehlerquellen?
- Geschäftslogik formalisieren: Wir haben die impliziten Regeln der Analysten explizit gemacht. Welche Validierungen wenden sie an? Welche Cross-Checks sind notwendig?
- Fachsprache als Code: Die Software spricht dieselbe Sprache wie die Analysten. Begriffe wie "EBIT", "Leverage Ratio", "Working Capital" sind keine Strings, sondern Geschäftskonzepte mit Bedeutung und Regeln.
- Human-in-the-Loop Design: Die AI extrahiert, aber Menschen können verifizieren. Jede Extraktion kommt mit der genauen Stelle im Dokument und einer Begründung.
Das Ergebnis: 80% der manuellen Arbeit automatisiert, Break-even nach 1,5 Monaten, höhere Qualität durch Konsistenz.
Warum generische Lösungen scheitern
Stellen Sie sich vor, Sie nehmen ein generisches RAG-System und werfen Ihre Dokumente rein. Was fehlt?
- Domänenlogik: Das System weiß nicht, was ein "EBIT" ist oder wie man es validiert
- Geschäftsregeln: Keine Ahnung, welche Cross-Checks notwendig sind
- Kontextverständnis: Kann nicht zwischen "EBIT 2024" und "forecast EBIT 2025" unterscheiden
- Fehlerhandling: Weiß nicht, was bei widersprüchlichen Informationen zu tun ist
Domain-Driven Design löst diese Probleme nicht durch mehr Daten oder bessere Modelle, sondern durch besseres Verständnis.
Die harte Wahrheit über Domänenwissen
Domänenwissen zu erwerben ist zeitaufwendig. Es bedeutet, mit Experten zu reden, Prozesse zu beobachten, Feedback einzuholen. Es bedeutet, nicht sofort mit dem Coden anzufangen.
Aber es ist die einzige Art, Systeme zu bauen, die nicht nur funktionieren, sondern die echte Geschäftsprobleme lösen.
Der Unterschied ist messbar: Systeme, die auf domänengetriebenem Design basieren, haben höhere Erfolgsquoten, kürzere Break-even-Zeiten und bessere Akzeptanz bei Nutzern.
Von der Technologie zur Domäne denken
Am Ende ist es eine Frage der Perspektive: Baue ich eine technische Lösung und hoffe, dass sie zum Problem passt? Oder verstehe ich das Problem erst und baue dann die Lösung?
Bei Klartext AI wählen wir immer die zweite Option. Nicht weil es einfacher ist – sondern weil es der einzige Weg ist, nachhaltige, wertvolle Systeme zu schaffen.
Domain-Driven Design ist kein Buzzword für uns. Es ist die Art, wie wir arbeiten.
