Warum DDD im Banking?
Domain-Driven Design ist kein neues Konzept, Eric Evans hat es 2003 publiziert. Aber es gibt Domänen, in denen DDD besonders gut funktioniert, und das Banking gehört zweifellos dazu. Die Gründe liegen auf der Hand: hohe Fachkomplexität, strenge Regulierung, gewachsene Systeme und eine klare Trennung zwischen IT und Fachbereich, die historisch oft mehr Hindernis als Vorteil war.
Im Kontext eines Mainframe-Refactoring-Projekts bei einer großen deutschen Bank wurde die Einführung von DDD nicht als akademische Übung betrieben, sondern als pragmatische Antwort auf ein konkretes Problem: Die Konfiguration von Mainframe-Services war über Jahrzehnte in einer Weise gewachsen, die niemand mehr vollständig durchschaute. Tausende von Konfigurationsparametern, verteilt über mehrere Systeme, ohne konsistentes Modell.
Bounded Contexts: Ordnung in der Komplexität
Der erste und wichtigste Schritt war die Identifikation von Bounded Contexts. In einem Bankenprojekt ist das nicht trivial, weil die organisatorischen Grenzen selten mit den fachlichen Grenzen übereinstimmen.
Für das Konfigurationsmanagement der Mainframe-Services haben sich folgende Bounded Contexts herauskristallisiert:
- Service Configuration: Die technische Konfiguration der einzelnen Mainframe-Services, Ports, Timeouts, Ressourcenlimits
- Deployment Management: Die Steuerung von Deployments und Rollbacks über verschiedene Umgebungen hinweg
- Compliance Tracking: Die lückenlose Dokumentation aller Konfigurationsänderungen für die Revision
- Access Control: Die Verwaltung von Berechtigungen, wer welche Konfigurationen ändern darf
Jeder dieser Contexts hat sein eigenes Modell, seine eigene Sprache und seine eigenen Regeln. Ein “Service” im Kontext von Service Configuration ist etwas anderes als ein “Service” im Kontext von Deployment Management. Diese Unterscheidung explizit zu machen, war einer der größten Erkenntnisgewinne des Projekts.
Ubiquitous Language: Brücke zwischen IT und Fachbereich
Im Banking ist die Kluft zwischen IT und Fachbereich traditionell groß. Die Fachabteilungen sprechen von “Geschäftsvorfällen”, “Buchungskreisen” und “Mandanten”. Die IT spricht von “Transactions”, “Tenants” und “Service Instances”. Beide meinen oft dasselbe, oder auch nicht. Genau diese Ambiguität führt zu Fehlern.
Die Ubiquitous Language zwingt dazu, sich auf eine gemeinsame Sprache zu einigen, die im Code genauso verwendet wird wie in Meetings und Dokumentation.
// Vorher: Technische Begriffe ohne fachlichen Bezug
class ServiceConfig {
private String instanceId;
private Map<String, String> params;
}
// Nachher: Fachliche Sprache im Code
class MainframeServiceKonfiguration {
private ServiceKennung serviceKennung;
private Buchungskreis buchungskreis;
private Konfigurationsparameter parameter;
private Aenderungshistorie historie;
}Die Entscheidung, deutsche Fachbegriffe im Code zu verwenden, war bewusst gewählt. Der Fachbereich konnte den Code lesen und Fehler in der Modellierung direkt erkennen. Das hat die Qualität der Abstimmung erheblich verbessert.
Aggregate Design: Konsistenzgrenzen definieren
Ein zentrales Designproblem war die Frage: Was gehört zusammen? In einem System mit tausenden Konfigurationsparametern ist die Versuchung groß, alles in ein großes Objekt zu packen. DDD gibt hier eine klare Antwort: Aggregates definieren Konsistenzgrenzen.
Die MainframeServiceKonfiguration wurde als Aggregate Root definiert, die ihre Invarianten selbst durchsetzt:
- Eine Konfigurationsänderung darf nur von einem berechtigten Benutzer durchgeführt werden
- Jede Änderung muss einen Änderungsgrund enthalten (Compliance-Anforderung)
- Bestimmte Parameter dürfen nur in bestimmten Umgebungen geändert werden
- Eine Konfiguration muss immer in einem validen Zustand sein, partielle Updates sind nicht erlaubt
Diese Regeln im Aggregate zu verankern, statt sie in einer Service-Schicht oder gar im UI zu prüfen, stellt sicher, dass sie nicht umgangen werden können.
Domain Events: Audit Trail als Nebeneffekt
In regulierten Branchen ist ein lückenloser Audit Trail Pflicht. Mit Domain Events ergibt sich dieser fast als Nebeneffekt eines sauberen Domain-Modells:
public class KonfigurationGeaendert implements DomainEvent {
private final ServiceKennung serviceKennung;
private final Benutzer geaendertVon;
private final Zeitpunkt zeitpunkt;
private final Aenderungsgrund grund;
private final Map<String, ParameterAenderung> aenderungen;
}Jedes Domain Event wird persistiert und kann nicht mehr verändert werden. Die Revision erhält damit eine vollständige, chronologische Dokumentation aller Änderungen, ohne dass dafür ein separates Logging-System aufgebaut werden muss.
Warum DDD in regulierten Domänen besonders gut funktioniert
Nach Abschluss des Projekts lassen sich die Vorteile von DDD im regulierten Umfeld auf einige Kernpunkte zusammenfassen:
| Anforderung | DDD-Lösung |
|---|---|
| Nachvollziehbarkeit | Domain Events als Audit Trail |
| Fachliche Korrektheit | Ubiquitous Language reduziert Missverständnisse |
| Compliance | Invarianten im Aggregate Root durchgesetzt |
| Revisionssicherheit | Event Sourcing ermöglicht vollständige Historisierung |
| Wartbarkeit | Bounded Contexts begrenzen die Auswirkung von Änderungen |
Die regulatorischen Anforderungen, die oft als Hindernis empfunden werden, sind in Wahrheit ein natürlicher Treiber für gutes Domain Modeling. Wenn das Gesetz verlangt, dass jede Änderung dokumentiert wird, dann ist Event Sourcing die eleganteste Umsetzung. Wenn die Revision verlangt, dass Regeln nicht umgangen werden können, dann sind Aggregates die richtige Abstraktion.
Fazit
DDD im Bankensektor ist kein Luxus, sondern eine Notwendigkeit, besonders wenn gewachsene Mainframe-Systeme modernisiert werden. Die Investition in ein sauberes Domain-Modell zahlt sich durch bessere Kommunikation zwischen IT und Fachbereich, höhere Codequalität und eingebaute Compliance-Unterstützung mehrfach aus. Der Schlüssel liegt darin, DDD nicht als theoretisches Framework zu betrachten, sondern als praktisches Werkzeug, das an die konkreten Anforderungen des Projekts angepasst wird.