© Ruslan Grumble/Shutterstock.com
Warum Domain-driven Design?

Fachlich sinnvoll schneiden …


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 [1], 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.

Indem die Definition auf einen Bounded Context eingeschränkt wird, kann ein Begriff wie „Buch“, der je nach Kontext oder Ansprechpartner unterschiedliche Bedeutungen hat, eindeutig definiert werden. Das erleichtert die Analyse. Gleichzeitig helfen Bounded Contexts dabei, das Softwaresystem zu strukturieren. Jeder Bounded Context hat ein eigenes Domänenmodell. Also gibt es ein Domänenmodell für die Suche, das neben relevanten Informationen über die Bücher auch die Logik für die Suche und beispielsweise die Suchpräferenzen der Benutzer umfasst. Für die Leihe gibt es ebenso ein Domänenmodell, das Bücher im Sinne der Leihe, Ausleihen, Informationen über die Benutzer und die Logik für die Leihe enthält.

Neben dieser Aufteilung in Bounded Contexts umfasst DDD auch Techniken dafür, wie diese Domänenmodelle umgesetzt werden können (Abb. 1). Dieser Bereich des taktischen Designs enthält Regeln, um ein gutes objektorientiertes Design zu erstellen. DDD ist also eine vollständige Architekturmethode, die Techniken für alle Granularitätsebenen anbietet. Die Bereiche des strategischen und taktischen Designs sind nahezu unabhängig voneinander: Man muss Bounded Contexts nicht objektorientiert umsetzen, wie es das taktische Design vorschlägt, son...

Neugierig geworden? Wir haben diese Angebote für dich:

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