Domain Driven Design

Vorgehensmodell für den skalierbaren Umgang mit Komplexität

Nur wer es schafft, mit Komplexität besser umzugehen, als seine Konkurrenten, wird langfristig bestehen. Dabei geht es nicht nur um den Umgang mit äußeren Einflüssen. Unternehmen selbst sind komplexe Systeme, die aus vielen (Fach-)Bereichen bestehen, von denen jeder seine eigene Verantwortungsstruktur und seine eigenen Ziele hat. Jeder Bereich verändert sich in einem anderen Tempo. Das Verhalten des Unternehmens als Ganzes ist das Ergebnis eines komplizierten Beziehungsgeflechts zwischen seinen Bereichen und Funktionen und deren Interaktionen und Abhängigkeiten. Die Volatilität und der rasche Wandel der Märkte und Vorschriften, in denen die Unternehmen tätig sind, erhöhen zusätzlich die Komplexität.

Eine bewährte Möglichkeit Komplexität zu bewältigen, besteht darin, sie in unabhängig verwaltete Teile aufzuteilen. Auf diese Weise kann jeder Bereich schnell vorankommen, ohne dass enge Synchronisationsabhängigkeiten zu anderen Teilen des Unternehmens bestehen. Damit diese Aufteilung in kleinere und autonomere Einheiten gelingt, braucht es ein Vorgehensmodell, welches auch agil mit Veränderungen umgehen kann. Der Bedarf von Daten in einer Domäne entstehen aus deren Umgang mit Komplexität. Deshalb muss man die Ziele, Dynamiken und Prozesse einer Domäne verstehen, um sie mit Hilfe von Daten und Software unterstützen zu können.

Domain-driven Design (DDD) ist ein erfolgreicher Ansatz Komplexität von Software zu beherrschen, der auch auf System- und Datenarchitekturen angewandt werden kann. Die Besonderheit liegt im kollaborativen Ansatz aus der Perspektive des Fachbereichs. So wie ein Unternehmen seine Arbeit in Geschäftsbereiche unterteilt, orientiert sich im Domain-driven Design die Struktur der Architektur und Technologie an diesen Domänen. DDD ist also kein Blueprint, wie etwas architektonisch oder technisch gestaltet werden muss. Es ist vielmehr ein analytischer Ansatz, komplexe fachliche Zusammenhängen so zu gestalten, dass konzeptionelle Integrität gewährleistet werden kann.

Im Zusammenspiel mit anderen Hilfsmitteln aus der agilen Softwareentwicklung wie Data Thinking, Scrum, Lean Launchpad, das JTBD Framework u. a. verfügen wir heute über einen mächtigen Werkzeugkasten zur Entwicklung von Datenplattformen, die vor allem auf die Bedarfe des Business einzahlen.

Die Business Logik wirklich verstehen

Um den Bedarf des Business wirklich zu verstehen bewegen wir uns im Domain Driven Design vom großen ganzen immer weiter ins Detail. Es geht darum, die wichtigsten Prozesse der zukünftigen Datenkonsumenten wirklich zu verstehen. Nur so lässt sich untersuchen, wie Sie es ihnen leicht machen können, ihre Arbeitsabläufe mit Hilfe der Plattform zu optimieren. Im ersten Schritt geht es um ein möglichst umfassendes Bild des Status Quo. Dazu gehören strategische Unternehmensziele, Geschäftsmodelle und auch technische Gegebenheiten. Dann geht man dort weiter ins Detail, wo der größte "Schmerz" besteht, ein hohes Risiko identifiziert wird oder es den größten Nutzen und idealerweise einen echten Wettbewerbsvorteil bringt. Solche Bereiche einer Domäne werden auch Core Domain genannt. An den Core Domains werden dann ereignisbasiert Abhängigkeiten und Engpässe zwischen Domänen ermittelt, bevor wir einzelne Kontexte näher untersuchen.
Ziel ist es ein bestmögliches gemeinsames Verständnis der fachlichen Anforderungen, Zusammenhänge und Engpässe zu erreichen, bevor konkrete Konzepte, Richtlinien oder Lösungen entwickelt werden können. Erst zuletzt werden auf dem Data Thinking Weg die identifizierten Use Cases evaluiert, um sie iterativ zur operativen Nutzung als Datenprodukte zu entwickeln.

Die zentrale - und doch so häufig unterschätzte - Bedeutung des Kontext

Um erfolgreich wissensbasiert zusammenzuarbeiten, muss vor allem die Fähigkeit entwickelt werden, Zusammenhänge herzustellen. Nicht isoliert durch den Einzelnen, sondern mit Hilfe eines Netzwerkes. Dafür muss über möglichst viele räumliche und organisatorische Grenzen hinweg kommuniziert und interagiert werden. Die Herausforderung dabei ist, dass sich die Bedeutung und Interpretation von Objekten oder Sachverhalten im Kontext verändert.

Ist jemand schon ein "Kunde", wenn er unseren Laden betritt? Oder erst nachdem er etwas gekauft hat? Ist er noch ein Kunde, wenn er die Ware wieder zurückgebracht hat? Selbst innerhalb einzelner Domänen (wie z. B. Sales) kann es je nach Use Case unterschiedliche Konzepte dafür geben, was genau ein Kunde ist.

Daraus erwächst ein zentrales Problem für die Modellierung von Softwaresystemen und Datenplattformen. Während wir Menschen "im Gespräch" meist recht schnell klären können, in welchem Kontext wir etwas betrachten, ist das für Maschinen nicht so einfach.

Eine gute Data Mesh System-Architektur orientiert sich deshalb immer am sogenannten "Bounded Context". Ein klar definierter Bereich, in welchem sprachliche Eindeutigkeit herrscht. Denn sprachliche Eindeutigkeit kann immer nur in einem definierten und abgegrenzten Kontext sichergestellt werden. Um die Domänen- und Kontext-Abhängigkeiten einer Organisation zu erkennen, können Bounded Context Canvases eingesetzt werden und durch Bounded Context Maps dann sichtbar gemacht werden.

Canvas "Bounded Context"

Um Probleme finden, analysieren und sie genau beschreiben zu können, sind neben dem Verständnis der Domänen zwei Bedingungen wichtig: Das Verstehen und Beschreiben in einer unmissverständlichen Sprache und der klar definierte Bounded Kontext, in dem die Terminologie eindeutig und das Lösungsmodell gültig ist.

Bounded Kontext und Domäne sind in der Regel nicht deckungsgleich! Je mehr Überschneidungen es zwischen Domänen und Kontexten gibt, desto komplizierter und desto weniger flexibel sind die resultierenden Systeme.

Systemdesign ist Kontextdesign

Systemdesign ist kontextbezogenes Design - es geht von Natur aus um Grenzen (was ist drin, was ist draußen, was ist übergreifend, was bewegt sich dazwischen) und um Kompromisse. Es formt neu, was draußen ist, genauso wie es das, was drinnen ist, formt.

Während Domänen und Sub-Domänen durch die Organisation selbst definiert werden, werden Bounded Kontexte durch Systemarchitekten entworfen. Bounded Kontexte sind letztlich die Bausteine für die "physische" Systemarchitektur. Je kleiner ein solcher Kontext gewählt wird, desto flexibler ist (später) das System. Gleichzeitig steigt jedoch die Zahl der Schnittstellen, so dass nicht automatisch kleiner immer besser sein muss. Denn kein Kontext arbeitet isoliert von allen anderen. Es gibt verschiedene Muster, wie eine Zusammenarbeit zwischen zwei Kontexten realisiert werden kann. In Bezug auf den Umgang mit Datenprodukten ist die Konsumenten-Produzenten Beziehung sicher die wichtigste. Hier herrscht in der Regel ein ungleiches Kräfteverhältnis, durch die gegebene Abhängigkeit. Diese können aber relativ leicht durch einen sogenannten "Anticorruption Layer" oder "Open Host Service" aufgelöst werden.

Sie wollen mehr über skalierbare Datenplattformen, das Data Mesh oder Domänen-getriebenes Design erfahren? Sie haben Lust sich einfach einmal unverbindlich auszutauschen? Kontaktieren Sie uns, wir sind gespannt darauf Ihre Sicht kennen zu lernen.