Diese Webseite der PPI verwendet Cookies. Durch die weitere Nutzung dieser Website stimmen Sie der Verwendung von Cookies zu. Weitere Informationen und Details zur Cookie-Verwendung lesen Sie in unserer Erklärung zum Datenschutz.
Microservice-Architekturen sind bei der Integration von Anwendungen in die Cloud zum Standard geworden. Von zentraler Bedeutung bei ihrer Modellierung sind die betreffenden Geschäftsbereiche mit ihren fachlichen Funktionalitäten. Deren Betrachtung hält jedoch zahlreiche Herausforderungen bereit. Die Experten der PPI setzen auf Domain Driven Design (DDD), dessen Werkzeuge und Methoden die Softwaremodellierung unterstützen und die Gesamtkomplexität reduzieren.
Softwareentwicklung auf Basis von Microservices wird immer mehr zum Standard. Wenn nicht ausschließlich, so aber ganz besonders mit Blick auf die Integration und Migration von Anwendungen in die Cloud. Unabhängig davon, ob es sich um eine Neuentwicklung, die Modernisierung oder die Ablösung einer Applikation handelt. Die Komplexität im Rahmen der Softwareentwicklung steigt stetig und diese gilt es beherrschbar zu machen.
Fachlichkeit als neue Basis
In der Vergangenheit waren die Daten beziehungsweise einzelne große Datenmodelle der maßgebliche Treiber für die Softwareentwicklung. Inzwischen rückt mit fortschreitender Digitalisierung zunehmend die Besinnung auf die Fachlichkeit als Basis der Modellierung in den Vordergrund.
Struktur und Kontextbezug
Softwareentwicklung beziehungsweise -weiterentwicklung ist kein Selbstzweck; sie dient dazu, real existierende Probleme zu lösen. Agile Vorgehensmodelle mit eigenverantwortlichen, selbst gesteuerten Teams sind dabei im Trend. Gerade in diesem Zusammenhang ist ein klarer fachlicher Kontextbezug nützlich. Und hier kommt das bereits 2003 von Eric Evans entwickelte Domain Driven Design (DDD) ins Spiel. Dessen Methoden und Werkzeuge strukturieren diese Fachlichkeit, teilen sie sinnvoll auf und stellen einen entsprechenden Kontextbezug her.
Bounded Context und Ubiquitous Language
Zunächst einmal gilt es, ein gemeinsames Verständnis über den Geschäftsbereich, die sogenannte Domäne, zu schaffen. Dabei spielen sogenannte Bounded Contexts eine wichtige Rolle. Dies sind abgegrenzte Bereiche innerhalb der Domäne mit entsprechend fachlichen Funktionalitäten, die separat betrachtet und modelliert werden. Sie bilden zugleich die Grenzen der Ubiquitous Language, was sich als allgegenwärtige Sprache übersetzen lässt. Diese ist für ein gemeinsames Kontextverständnis elementar und beschreibt eindeutig die Definition und Verwendung von Begrifflichkeiten und Funktionalitäten innerhalb eines Bounded Context. Wie so etwas aussieht, lässt sich am Beispiel einer Adresse im Rahmen einer Baufinanzierung verdeutlichen. Im Kontext ‚Kunde‘ spiegelt sie die Wohnanschrift des Antragstellers dar, im Kontext ‚Finanzierungsobjekt‘ dagegen referenziert sie auf die Anschrift des zu finanzierenden Objektes.
Interdisziplinäre Teams
Hinsichtlich der Verantwortung gilt der Grundsatz „ein Bounded Context – ein interdisziplinäres Team“. Soll heißen: In der Regel sollten keinesfalls mehrere Teams an einem Bounded Context arbeiten. Sehr wohl können aber mehrere abgegrenzte Bereiche einer Arbeitsgruppe zugeordnet werden. Unter agilen Aspekten bestehen interdisziplinäre Teams aus Mitarbeitern mit unterschiedlichen Rollen, was auch zu einer Neuausrichtung des grundsätzlichen Rollenverständnisses der Beteiligten führt. (Projekt-) Manager, Businessanalysten und Entwickler sind für den Softwareentstehungsprozess im Rahmen ihres Bounded Context gemeinschaftlich verantwortlich. Umso größer ist die Notwendigkeit für ein einheitliches Verständnis der Domäne sowie des Geschäftsbereichs mit ihren jeweiligen Funktionalitäten und für eine einheitliche Sprache innerhalb des Teams.
Subdomänen reduzieren die Komplexität
Überschreitet die Komplexität und Größe eines Geschäftsbereiches ein bestimmtes Maß, so hilft die Unterteilung in zusätzliche Subdomänen. Insbesondere dann, wenn sich einzelne Bestandteile der Ubiquitious Language nicht auf einen Bounded Context eingrenzen lassen. Diese Bausteine zu erkennen kann mitunter herausfordernd sein. Durch eine weitere Unterteilung lässt sich in einem solchen Fall die Komplexität innerhalb der einzelnen Subdomäne weiter reduzieren.
Context Map verschafft den Überblick
Bounded Context und Subdomänen sind nur selten isoliert betrachtbar. In der Regel bestehen – teilweise komplexe – Zusammenhänge zwischen Subdomänen. Diese bedingen eine Interaktion und Kommunikation, für die entsprechende Schnittstellen zu beschreiben sind. Am Ende steht ein Bild sämtlicher Funktionalitäten, die innerhalb der ursprünglichen (Ober-)Domäne zur Lösung der fachlichen Problemstellung definiert wurden, die sogenannte Context Map.
Domain Driven Design – die wichtigsten Merkmale
Im Rahmen der Softwareentwicklung auf Basis von Microservices spielt DDD als Modellierungs- und Entwurfsdisziplin eine immer größere Rolle. Kernpunkte sind dabei:
ein fachlich real existierendes Problem mit entsprechender Komplexität
daraus abgeleitete eindeutige Geschäftsbereiche (Domänen) mit fachlich sinnvoller Unterteilung in Bounded Context und Subdomänen
eine einheitliche Sprache sowie ein einheitliches Domänenverständnis
interdisziplinäre Teams mit neuem Rollenverständnis
eine Darstellung in gemeinsamen Modellen
eine Einbindung in den Gesamtkontext
Die erfahrenen Berater von PPI helfen bei der Anwendung von DDD-Konzepten und unterstützen Finanzdienstleister dadurch bei der erfolgreichen Lösung von Problemstellungen im Rahmen einer fachorientierten Softwareentwicklung.
Cloud Banking – unsere Leistungsangebote und Unterstützung. Wir verstehen Bank-IT!
