Große Systeme mit Domain-driven Design entwerfen
Wer die Konzepte von DDD richtig einzuordnen weiß, kommt mit einem strukturierten Ansatz recht einfach zu guten Ergebnissen.
- Eberhard Wolff
Domain-driven Design [1] teilt große Systeme in Bounded Contexts auf, von denen jeder ein eigenes Domänenmodell hat, um einen Teil der Fachlichkeit weitgehend unabhängig zu erbringen. In einem System für eine Bibliothek könnte es einen Bounded Context für das Ausleihen von Büchern und einen anderen für die Suche geben. Das eine Domänenmodell hätte dann die Informationen für die Leihe wie die Anzahl der Exemplare eines Buchs. Beim Domänenmodell für die Suche spielt die Anzahl keine Rolle, dafür sind Autor oder Titel wichtige Informationen.
Beziehungen zwischen Bounded Contexts
Domain-driven Design bietet Ansätze, um das benötigte Integrieren der Bounded Contexts durchzuführen (s. Abb. 1). Am Anfang steht die Analyse, in welcher Beziehung Bounded Contexts zueinander stehen. Die Arten der Beziehung sind folgende:
- Free bedeutet, dass die Arbeit an einem Bounded Context wenig Auswirkungen auf die Arbeit an anderen Bounded Contexts hat,
- bei Upstream-Downstream ist der Erfolg des Teams, das den Bounded Context im Downstream bearbeitet, von dem Team abhängig, das den im Upstream in Arbeit hat,
- Mutually Dependent bedeutet, dass die Teams beide Systeme nur zusammen erfolgreich liefern können.
Welche Beziehung vorliegt, lässt sich fast immer durch die Analyse der Bounded Contexts ermitteln. Es ist also meistens keine Designentscheidung, sondern ergibt sich aus der Aufteilung.
Zurück zum Beispiel der Bibliothek: Deren Besucher suchen zunächst Bücher und leihen sie anschließend aus. Bei "Leihe" und "Suche" kommt Free somit nicht in Frage, da es eine Möglichkeit geben muss, gefundene Bücher auszuleihen. Daher haben die beiden Bounded Contexts eine Beziehung.
Der Erfolg der "Leihe" ist wahrscheinlich gegeben, wenn sich Bücher ausleihen lassen. Der Erfolg der "Suche" hingegen bedeutet vermutlich, dass das Finden der Bücher erfolgreich ist. Besucher können ein Buch nur leihen, wenn sie es vorher gefunden haben. "Leihe" ist damit Downstream zu "Suche" und umgekehrt "Suche" Upstream zu "Leihe".
Mutually Dependent ist die Beziehung nicht: Zum einen geht sie nur in eine Richtung und ist daher nicht gegenseitig (mutually) und zum anderen gibt es in der "Suche" und "Leihe" genügend Bereiche und Features, die sich unabhängig voneinander entwickeln lassen. Die Ergänzung der Suche um neue Kriterien hat beispielsweise keine Auswirkungen auf die Leihe.
Primär schlagen sich die Beziehungen in der Organisation und Koordination zwischen den Teams nieder und nicht in den Softwareartefakten. Dennoch sind es zusätzlich Ergebnisse der Relationen auf Softwareebene: Zwei Bounded Contexts mit einer Schnittstelle können kaum Free sein.
Auf der Organisationsebene sind die Beziehungen ein direktes Ergebnis der Softwareartefakte. Wenn ein Team die Verantwortung für einen Downstream Bounded Context übernimmt, bekommt es die passende Downstream-Rolle. Es ist genau genommen nicht das Team selber, das die Beziehung hat, sondern der Bounded Context gibt die Beziehung an das Team weiter.
