Eberhard Wolff INNOQ

„Am Ende ist DDD nur ein weiteres Werkzeug, um bessere Software zu schreiben. Es lohnt sich, DDD genauer zu betrachten, um so das Werkzeug möglichst genau kennenzulernen. Das ist vor allem wichtig, weil Softwareentwicklung oft nicht effektiv ist, da Konzepte nur halb verstanden oder umgesetzt werden. DDD ist jedoch keine Religion, wie Eric Evans selbst schon gesagt hat. Es ist also völlig in Ordnung, nur Teile von DDD zu nutzen oder die Konzepte weiterzuentwickeln.“

Domain-driven Design (DDD) ist eine alte Technik, aber gerade voll im Trend. Worum geht es bei DDD und ist der Hype berechtigt?

Domain-driven Design (DDD) geht auf das gleichnamige Buch von Eric Evans zurück, das 2004 erschienen ist. Also ist DDD fünfzehn Jahre alt. Die IT-Industrie behauptet von sich, sehr schnelllebig zu sein. Dann sollte ein Buch dieses Alters keine Rolle mehr spielen. Aber das Gegenteil ist der Fall: Das Buch verkauft sich immer noch sehr gut. Das Thema DDD ist im Moment sogar so präsent wie schon lange nicht mehr.

Für diese erstaunliche Entwicklung gibt es verschiedene Gründe. Das Besondere an DDD drückt schon der Begriff aus: Die Domäne soll das Design treiben. Anders gesagt: Architektur und Implementierung orientieren sich konsequent an der Fachlichkeit. Da die meiste Software speziell für die Unterstützung fachlicher Prozesse implementiert wird, ist die Ausrichtung an der Fachlichkeit eigentlich eine offensichtliche Möglichkeit, um fachliche Prozesse noch besser zu unterstützen.

Kern von DDD ist die Ubiquitous Language (allgegenwärtige Sprache). Diese Sprache besteht aus allen Begriffen, die Domänenexperten benutzen, wenn sie über die Domäne sprechen. Tatsächlich zeigt die Erfahrung, dass Projekte ihre ganz eigene Sprache entwickeln. Die Begriffe aus der Sprache sollen dann auch im Code und in der Datenbank genutzt werden, um Felder, Klassen, Spalten oder Tabellen zu benennen. Dadurch wird es einfacher, die Fachlichkeit in der Software umzusetzen: Die fachlichen Begriffe müssen nicht noch in andere Begriffe übersetzt werden, die bei der technischen Umsetzung genutzt werden. Damit verschwimmen die Grenzen zwischen den Modellen, die für Analyse, Implementierung und Architektur genutzt werden. Das vereinfacht Feedback über diese Modelle gerade von Domänenexperten.

DDD gibt sowohl Architekten als auch Entwicklern konkrete Techniken an die Hand, um die Fachlichkeit geschickt umzusetzen. Das ist eine wichtige Besonderheit von Domain-driven Design: Es betrachtet völlig verschiedene Ebenen wie Architektur und Code. Das strategische Design teilt ein System in grobgranulare Bounded Contexts auf. Der Begriff Bounded Context sagt schon, dass es um das Begrenzen geht. Ein Bounded Context ist ein begrenzter Bereich, in dem eine Ubiquitous Language definiert ist. In einer Bibliothek ist der Begriff „Buch“ für den Bounded Context „Suche“ ein Datensatz, wie man ihn früher auf eine Karteikarte geschrieben hat. Zu dem Buch gehören der Autor, der Titel oder die Schlagwörter. Für die Leihe ist das „Buch“ hingegen ein konkretes Exemplar, das ausgeliehen werden kann. Relevant ist dabei beispielsweise, ob das Buch so gut erhalten ist, dass es noch ausgeliehen werden kann. Der Begriff „Buch“ ist dabei sehr unterschiedlich definiert: Für die Suche hat ein Buch beispielsweise mehrere ISBNs, da die Druckausgabe und die E-Books unterschiedliche ISBNs haben, aber unter einem Suchergebnis zusammengefasst werden. Für die Leihe haben mehrere „Bücher“ dieselbe ISBN. Das Buch in der Leihe ist also keineswegs identisch mit dem Buch in der Suche.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 9.19 - "Ass im Ärmel?"

Alle Infos zum Heft
579901169Warum Domain-driven Design?
X
- Gib Deinen Standort ein -
- or -