© Elya Vatel/Shutterstock.com
Architektur innerhalb eines Bounded Context

DDD: taktisches Design


Im Artikel von Carola Lilienthal und Michael Plöd [1] wurde gezeigt, wie man eine Domäne in mehrere Bounded Contexts aufteilt. Dabei erhalten wir statt einem großen, schwer verständlichen und schwer wartbaren Domänenmodell nun mehrere, besser handhabbare Domänenmodelle. In diesem Teil der Serie schauen wir darauf, wie man das einzelne Domänenmodell konkret implementieren kann.

Bei der Implementierung des einzelnen Domänenmodells ist zweierlei relevant: erstens die gröbere Architektur in Schichten, Hexagonen oder Ringen und zweitens die feinere Architektur, die sich in der Mustersprache in den sogenannten Building Blocks ausdrückt.

Schichten, Hexagone, Ringe

Ursprünglich wurde Domain-driven Design [2], [3], [4] mit einer Schichtenarchitektur (Layered Architecture) als Metapher entworfen [5]. Es gibt vier Schichten (Layers): UI, Application, Domain und Infrastructure Layer. Als einzige Regel in diesem Architekturstil gilt: Oben darf unten benutzen, aber unten nicht oben. In der Softwaretechnik wird dann noch zwischen strikter und nichtstrikter Schichtenarchitektur unterschieden: Bei ersterer darf eine Schicht nur die direkt darunterliegende Schicht verwenden, bei zweiterer alle darunterliegenden Schichten.

Für den Domain Layer, der uns wenig überraschend in Domain-driven Design am meisten interessiert, gibt es verschiedene Arten, ihn zu implementieren: Transaction Script, Table Module, Anemic Domain Model, Domain Model [6]. Ein großer Vorteil von strategischem Design ist, dass wir für unterschiedliche Bounded Contexts unterschiedliche Arten wählen können. Jeder Bounded Context kann also eine andere Architektur implementieren. Taktisches Design kommt dann zum Einsatz, wenn wir die Implementationsart Domain Model verwenden. Dabei modellieren wir die Domäne in Code ganz unabhängig von einer möglicherweise darunterliegenden Datenbank und sonstiger Technologie.

Die Schichtenarchitektur ist eine gute erste Näherung, um zu beschreiben, was erlaubt und was verboten ist. Allerdings reicht sie noch nicht aus. Denn eben haben wir gelernt, dass wir das Domänenmodell von Technologie freihalten sollen. Und da kommt es zu einem Widerspruch, denn die Schichtenarchitektur erlaubt den Zugriff von Domain auf Infrastructure. Andere Autoren haben deshalb Hexagone (Ports and Adapters Architecture) oder Ringe (Clean Architecture, Onion Architecture [7]) als Architekturmetapher vorgeschlagen. Statt oben/unten sprechen wir dann von innen/außen. Statt einem Domain Layer haben wir d...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang