In der Softwareentwicklung geht der Trend seit Jahren weg von monolithischen Software-Architekturen hin zu modular strukturierten Komponenten. Speziell im Finanzsektor sind historisch gewachsene, komplexe Kernbanksysteme aber eher noch die Regel als die Ausnahme. Im Zuge der digitalen Transformation steigt jedoch auch in der Bankbranche die Forderung nach mehr Agilität und Skalierbarkeit in der IT. Um diesen Ansprüchen gerecht zu werden, bedarf es bei der Modernisierung einer Vorgehensweise, die sich auf Fachlichkeit konzentriert und gleichzeitig Komplexität bewältigen kann: Domain-Driven Design.
Eine große Menge an zu verarbeitenden Daten, individuellen Vorgängen und komplexen Abläufen machen jedes Softwareprojekt im Finanzsektor zu einer Herausforderung. Die Realisierung stellt sowohl die Softwareentwickler als auch die Fachexperten vor eine schwierige Aufgabe, da viele Aspekte berücksichtigt und nachvollziehbar umgesetzt werden müssen. Noch wichtiger: Beide Seiten müssen bereits bei der Planung dieselbe Sprache sprechen, um die spezifischen fachlichen Anforderungen technisch einwandfrei umsetzen zu können. Der Einsatz einer Vorgehensweise wie Domain-Driven Design (DDD) ermöglicht es, diese Anforderungen deutlich abzugrenzen, für alle Beteiligten verständlich zu definieren und so auch umfangreiche Softwarelösungen für Banken klar strukturiert zu realisieren. Dies entspricht auch der grundsätzlichen Tendenz im IT-Bereich, sich weg von monolithischen Systemen, hin zu einer feingliedrigen Struktur aus Microservices zu bewegen.
Was ist Domain-Driven Design?
Am Anfang der meisten Projekte stehen viele Fragezeichen. Anforderungen müssen geklärt und Geschäftsprozesse richtig verstanden werden, bevor auch nur ansatzweise mit der Programmierung der Software begonnen werden kann. Hier setzt DDD an: Entkoppelt von technischen Details unterstützt DDD Entwickler und Fachexperten zunächst dabei zu planen, wie Fachlichkeit und Fachlogik sinnvoll innerhalb der Softwarearchitektur abgebildet werden können.
Eric Evans, Experte und Unternehmensberater in Sachen Software-Design, prägte den Begriff Domain-Driven Design bereits Anfang der 2000er in seinem Buch Domain-Driven Design. Tackling Complexity in the Heart of Software. Darin beschreibt er die Methode als strategischen Ansatz aus sprach- und domänenzentrierten Prinzipien und Mustern zur Modellierung komplexer Softwaresysteme.
Von der unübersichtlichen Domäne zum strukturierten Domänenmodell
Eine Domäne ist der Wissensbereich, für den die Softwarelösung erstellt werden soll. Sie beschreibt Fachlichkeit mit all ihren Prozessen, Elementen und deren Beziehungen und Abhängigkeiten untereinander. DDD basiert darauf, dass sich alle Projektbeteiligten bereits zu Beginn des Lebenszyklus der Software eingehend mit der Domäne beschäftigen. Das Fachwissen der Domänenexperten soll dabei so kommuniziert und strukturiert werden, dass Architekten und Entwickler ein umfassendes, gemeinsames Verständnis aller fachlichen Herausforderungen erlangen.
So entsteht ein Domänenmodell, das sämtliche fachlichen Zusammenhänge abbildet und Domänenwissen in abstrahierter, strukturierter Form darstellt. Evans beschreibt es als „eine Reihe von Konzepten, die in den Köpfen der Projektbeteiligten entstanden sind, mit Begriffen und Beziehungen, die das Verständnis von Domänen widerspiegeln“.
Das Domänenmodell ist kein von der Software abgetrennter Bereich, sondern soll sich mit ihr weiterentwickeln. Code und Modell bedingen sich im DDD-Konzept gegenseitig und sollten sich zu jeder Zeit auf demselben Stand befinden. Wird festgestellt, dass sich die im Modell festgelegten Elemente so nicht im Code umsetzen lassen, wird das Domänenmodell erneut angepasst. Denn nur wenn der DDD-Ansatz konsequent verfolgt wird, ist sein Mehrwert für das Projekt sichergestellt und für einen effektiven Entwicklungsprozess gesorgt, bei dem sowohl Fach- als auch Entwicklerseite den Überblick behalten.
Kommunikation ist der Schlüssel zu konsistenten Projekten
Die im Domänenmodell festgelegten Elemente und Zusammenhänge müssen in einer – für Domänenexperten und Entwickler gleichermaßen – verständlichen Form kommuniziert werden. So entsteht die sogenannte Ubiquitous Language, eine allgemeingültige Sprache, „die auf die Domäne zugeschnitten und gleichzeitig präzise genug für die technische Entwicklung ist“, so Evans. Diese domänenbezogene Sprache dient als Basis für die gesamte Kommunikation im Team. Sie zieht sich wie ein roter Faden durch das Projekt und wird von allen Beteiligten verwendet, um zentrale Begriffe und deren Beziehungen zueinander eindeutig zu klären. Diese Fachbegriffe sollten immer mit dem gleichen Verständnis verwendet werden, egal ob bei der Dokumentation, den Tests, der Spezifizierung von Anforderungen oder im Code selbst.
DDD wirkt damit dem entgegen, was Evans als eine der größten Herausforderungen in Projekten mit vielen interdisziplinären Berührungspunkten identifiziert – einer uneinheitlichen sprachlichen Basis. Missverständnisse und Fehlinterpretationen zwischen Fachseite und IT werden durch den Einsatz der Ubiquitous Language bei der Modellierung der fachlichen Lösungen vermieden.
Ohne Kontext keine Bedeutung
Mit der Ubiquitous Language als Werkzeug wird das Domänenmodell aufgegliedert. Alle geschäftlichen Kontexte werden definiert und ihre Grenzen genau abgesteckt; man spricht hierbei von Bounded Contexts. Die sprachliche Eindeutigkeit ist nur innerhalb eines abgegrenzten Bounded Context gegeben, weswegen sich Fachbegriffe und geschäftsrelevante Prozesse auf genau einen Kontext beziehen müssen. So sind Doppelungen im System ausgeschlossen.
Das Konzept „Kunde“ ist ein weitverbreitetes Beispiel für dieses Prinzip. Ist jemand erst ein Kunde, wenn er etwas kauft oder reicht es aus, wenn er eine Website besucht? Werden Begriffe wie „Nutzer“, „Anwender“ oder „Besucher“ synonym verwendet? Der jeweilige Kontext ist entscheidend für die Begriffsbedeutung und die daraus resultierenden Beziehungen und Interaktionen.
Eine Context Map stellt einen Überblick über mehrere Bounded Contexts dar und bildet ihre technischen und organisatorischen Beziehungen und Abhängigkeiten ab. Die mit dem jeweiligen Kontext verknüpfte Begriffsdefinition führt zu einem Softwaresystem, das auch über wechselnde Rahmenbedingungen des Projekts hinweg, wie Veränderung der technischen Infrastruktur oder wechselnde Teams, stabil bleibt.
Vom fachlichen Modell zur komplexen Software
Wie wird aus trockener Theorie lebendige Software? Christian Sternkopf ist zuständig für das Produktmanagement bei knowis. Als Produktverantwortlicher berichtet er von seinen Erfahrungen mit DDD und beschreibt, wie es bei den knowis-Softwarelösungen eingesetzt wird.
Domain Driven Design ist angesichts der Schnelllebigkeit digitaler Technologien eher ein bereits bewährtes Konzept. Warum erlebt der Design-Ansatz gerade so viel Aufmerksamkeit?
Die Erklärung dafür ist der momentane Trend, Microservices-Architekturen zu bauen. Softwarearchitekten entdecken das Potenzial von DDD gerade bei deren Modellierung wieder, weil die mit DDD fachlich geschnittenen Kontexte, die Bounded Contexts, eine Art Schablone für Microservices darstellen. Das sind autonome Komponenten, die monolithische Anwendungen in kleine und agile Architektur-Einheiten aufbrechen.
Wie kommt DDD bei knowis zum Einsatz?
Das ist spannend, denn DDD wird bei knowis sogar auf zwei Arten eingesetzt. Zum einen nutzen wir es im Entwicklungsprozess komplexer Produkte – das erfordert natürlich jede Menge Disziplin, die sich aber lohnt. Wir als Bankingsoftware-Anbieter profitieren von der Brücke, die DDD zwischen den Beteiligten aus Fach- und Technologieseite schlägt. Hier erleichtert es die Zusammenarbeit bei der Produktentwicklung durch die Verwendung einer gemeinsamen Sprache.
Zum anderen unterstützt unser Produkt die DDD-Grundprinzipien und erlaubt es so, theoretische Konzepte direkt in ein fachliches Modell zu übertragen. Business-Analysten und Solution Engineers arbeiten in unserer Anwendung gemeinsam am selben Modell, aus dem eine stabile Software hervorgeht.
Gibt es eine optimale Herangehensweise an DDD?
Um eine Domäne zu modellieren ist es essenziell, die fachlichen Anforderungen zu kennen, die die Softwarelösung letztendlich erfüllen soll. Ein guter Ausgangspunkt kann es daher sein, User Stories, also Nutzerbedürfnisse, mittels User Story Mapping zu ermitteln.
Geht es darum, Microservices mittels DDD zu erstellen, sind fachliche Ereignisse, sogenannte Domain Events, ein zentraler Baustein. Sie dienen dazu, Domänen über verschiedene Microservices hinweg zu entkoppeln. Um Events und ihre Abhängigkeiten zu ermitteln kann zum Beispiel Event Storming sinnvoll sein – ein interaktiver Workshop, der die Planung komplexer Software vereinfachen soll und auf dem DDD perfekt aufbauen kann.
Fazit
Komplexe Softwaresysteme sind ohne fachliche Modellierung kaum zu beherrschen. Eine stabile IT-Architektur baut auf einer modularisierten, logisch strukturierten Fachlichkeit auf, die sich aus den DDD-Kernkonzepten Domänenmodell, Ubiquitous Language und Bounded Context entwickelt. Die konsequente Umsetzung von DDD in Projekten mit hoher Komplexität führt zu einer stabileren, effizienteren Software, die durch die saubere Trennung der fachlichen Kontexte leichter an sich verändernde Geschäftsprozesse angepasst und erweitert werden kann. Auf Basis dieser Softwarearchitektur entstehen skalierbare und flexible Lösungen, auf die Banken heute und in Zukunft angewiesen sind.
Bildquellen: Teaser: fanjianhua - 636173198 - iStock; Infografik: knowis AG
