© graja/Shutterstock.com
Java Magazin
DDD-Serie, Teil 1: 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?

Eberhard Wolff


ArtikelserieTeil 1: Warum Domain-driven Design?Teil 2: Strategic Design Teil 3: Ubiquituous Language Teil 4: Taktisches Design Teil 5: DDD und Microservices

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...

Java Magazin
DDD-Serie, Teil 1: 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?

Eberhard Wolff


ArtikelserieTeil 1: Warum Domain-driven Design?Teil 2: Strategic Design Teil 3: Ubiquituous Language Teil 4: Taktisches Design Teil 5: DDD und Microservices

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...

Neugierig geworden?


    
Loading...

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