Domain Driven Design

Der Weg zur Domänen-zentrierten Datenarchitektur

Unternehmen 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 Möglichkeit, die 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. So wie ein Unternehmen seine Arbeit in Geschäftsbereiche unterteilt, kann und sollte sich die Technologie an diesen Domänen orientieren.

Domain-driven Design (DDD) ist ein bewährter und sehr erfolgreicher Ansatz Komplexität von Software zu beherrschen. Die Besonderheit liegt im kollaborativen Ansatz aus der Perspektive des Fachbereichs. 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. 

DDD


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 zusammen zu arbeiten 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ück gebracht 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 so genannten "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.

Five1 Canvase - Bounded Context
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 ein 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 so genannten "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.

Was können wir für Sie tun?


Five1 Blog - Beiträge im Kontext Domain Driven Design