Einführung in Domain-Driven Design (eBook)

Vorwort

Ich erinnere mich noch lebhaft an den Tag, an dem ich meinen ersten Job in der Softwareentwicklung antrat. Ich war gleichzeitig euphorisch und eingeschüchtert. Nachdem ich während meiner Zeit auf dem Gymnasium Software für lokale Firmen zusammengehackt hatte, wollte ich nun unbedingt ein »richtiger Programmierer« werden und Code für eine der größten Outsourcing-Firmen des Landes schreiben.

In meinen ersten Tagen dort zeigten mir meine neuen Kolleginnen und Kollegen die wichtigsten Dinge. Nach dem Einrichten des Firmen-E-Mail-Kontos und dem Vertrautmachen mit dem Zeiterfassungssystem ging es endlich um die interessanten Dinge: die Coding-Richtlinien und -Standards des Unternehmens. Mir wurde gesagt: »Hier schreiben wir immer gut designten Code, und wir verwenden Schichtenarchitektur.« Wir gingen die Definition jeder der drei Schichten durch – Datenzugriffs-, Business-Logik- und Präsentationsschicht – und sprachen dann über die Technologien und Frameworks für die jeweiligen Anforderungen der Schichten. Damals wurden Daten mit dem Microsoft SQL Server 2000 gespeichert, der mithilfe von ADO.NET in die Datenzugriffsschicht integriert wurde. Die Präsentationsschicht setzte wahlweise auf WinForms für Desktopanwendungen oder auf ASP.NET WebForms für das Web. Wir verbrachten recht viel Zeit mit diesen beiden Schichten, und es verwirrte mich, dass die Business-Logik-Schicht kaum Aufmerksamkeit erhielt:

»Aber was ist mit der Business-Logik-Schicht?«

»Die ist ganz einfach. Da implementierst du die Business-Logik.«

»Aber was ist Business-Logik?«

»Ach, Business-Logik sind all die Schleifen und if-else-Anweisungen, die du brauchst, um die Anforderungen zu erfüllen.«

An diesem Tag begann meine Forschungsreise, auf der ich herausfinden wollte, was genau Business-Logik ist und wie sie eigentlich in gut designtem Code implementiert werden sollte. Es dauerte mehr als drei Jahre, bis ich endlich die Antwort fand.

Sie lag in Eric Evans bahnbrechendem Buch Domain-Driven Design: Tackling Complexity in the Heart of Software. Es stellte sich heraus, dass ich nicht falschlag. Business-Logik ist tatsächlich wichtig – sie ist das Herz der Software! Leider dauerte es aber weitere drei Jahre, bis ich die Weisheiten verstand, die Eric mir mitteilte. Das Buch ist sehr fortgeschritten, und die Tatsache, dass Englisch nur meine Drittsprache ist, hat dabei nicht geholfen.

Schließlich fügte sich aber alles zusammen, und ich schloss meinen Frieden mit Domain-Driven Design (DDD). Ich lernte die Prinzipien und Patterns von DDD kennen sowie die Feinheiten des Modellierens und Implementierens der Business-Logik und wie man die Komplexität im Herzen der Software angeht, die ich gerade baute. Trotz der Schwierigkeiten war es das wert. Meine Karriere verlief durch Domain-Driven Design deutlich anders.

Warum ich dieses Buch geschrieben habe

In den letzten zehn Jahren habe ich meinen Kolleginnen und Kollegen bei den unterschiedlichsten Firmen Domain-Driven Design vorgestellt und Kurse online wie offline darüber gehalten. Die Perspektive des Lehrers hat mir nicht nur dabei geholfen, mein Wissen zu vertiefen, sondern auch, die Art und Weise zu optimieren, wie ich die Prinzipien und Patterns von Domain-Driven Design vermittle.

Wie so oft ist Unterrichten noch herausfordernder als Lernen. Ich bin ein großer Fan der Arbeit und der Vorträge von Eliyahu M. Goldratt (https://de.wikipedia.org/wiki/Eliyahu_M._Goldratt). Eliyahu hat gerne erzählt, dass selbst die komplexesten Systeme inhärent einfach sind, wenn man sie aus dem richtigen Winkel betrachtet. In all den Jahren, in denen ich DDD lehre, war ich auf der Suche nach einem Modell der Methodik, die die inhärente Einfachheit von Domain-Driven Design aufzeigt.

Dieses Buch ist das Ergebnis meiner Bemühungen. Sein Ziel ist es, Domain-Driven Design zu demokratisieren – es leichter zu verstehen und es besser einsetzen zu können. Ich glaube, dass die DDD-Methodik von unschätzbarem Wert ist, insbesondere wenn Sie moderne Softwaresysteme entwerfen. Dieses Buch wird Ihnen genug Werkzeuge an die Hand geben, um bei Ihrer tagtäglichen Arbeit mit dem Anwenden von Domain-Driven Design beginnen zu können.

Wer dieses Buch lesen sollte

Ich denke, dass das Wissen um Prinzipien und Patterns von Domain-Driven Design für die Softwareentwicklung auf allen Ebenen nützlich ist – beim Einstieg in die Entwicklung, während man besser wird bis hin zur Arbeit auf Leitungsebene. DDD stellt nicht nur Werkzeuge und Techniken zum Modellieren und effektiven Implementieren von Software bereit, es beleuchtet zudem einen häufig übersehenen Aspekt der Softwareentwicklung – den Kontext. Ausgestattet mit dem Wissen über das Business-Problem des Systems, werden Sie beim Wählen einer passenden Lösung viel effektiver sein, einer Lösung, die nicht zu sehr vereinfacht noch zu »overengineert« ist, sondern die Bedürfnisse und Ziele des Business erfüllt.

Domain-Driven Design ist für die Softwarearchitektur sogar noch wichtiger – und insbesondere für angehende Softwarearchitektinnen und -architekten. Seine Tools für strategische Designentscheidungen werden Ihnen dabei helfen, ein großes System in Komponenten zu unterteilen – Services, Microservices oder Subsysteme – und zu designen, wie die Komponenten miteinander interagieren, um ein System zu bilden.

Und schließlich werden wir in diesem Buch darüber sprechen, wie Sie nicht nur Software designen, sondern auch, wie Sie das Design parallel zu Änderungen im Business-Umfeld weiterentwickeln. Dieser wichtige Aspekt der Softwareentwicklung wird Ihnen dabei helfen, das Systemdesign mit der Zeit »in Form« zu halten und zu verhindern, dass es sich in einen Big Ball of Mud verwandelt.

Übersicht über das Buch

Dieses Buch ist in vier Teile unterteilt: strategisches Design, taktisches Design, DDD in der Praxis und die Beziehung zwischen DDD und anderen Methodiken und Patterns. In Teil I stellen wir Werkzeuge und Techniken für Entscheidungen zu umfassenden Designfragen vor. In Teil II konzentrieren wir uns auf den Code – die verschiedenen Wege, die Business-Logik in ein System zu integrieren. Teil III behandelt Techniken und Strategien für das Anwenden von DDD auf reale Projekte. Und in Teil IV geht es ebenfalls um Domain-Driven Design, nun aber im Kontext anderer Methodiken und Patterns.

Dies werden Sie im jeweiligen Kapitel finden:

• Kapitel 1 setzt den Rahmen für ein Softwareentwicklungsprojekt: die Fachdomäne, ihre Ziele und wie die Software sie unterstützen soll.
• Kapitel 2 stellt die Idee einer »Ubiquitous Language« vor: die Praktik von Domain-Driven Design für eine effektive Kommunikation und Wissensvermittlung.
• Kapitel 3 behandelt den Umgang mit der Komplexität von Fachdomänen und das Designen der High-Level-Architektur-Komponenten des Systems: Bounded Contexts.
• Kapitel 4 untersucht die verschiedenen Patterns (Entwurfsmuster) zum Organisieren der Kommunikation und zur Integration der Bounded Contexts.
• In Kapitel 5 beginnt der Einstieg in die Implementierungs-Patterns für die Business-Logik mit zwei Patterns, die für die einfache Business-Logik gedacht sind.
• In Kapitel 6 geht es weiter zu komplexer Business-Logik und dem dazu passenden Domain Model Pattern.
• Kapitel 7 ergänzt die Zeit-Perspektive und es führt einen noch fortgeschritteneren Weg zum Modellieren und Implementieren von Business-Logik ein: das Event-Sourced Domain Model.
• In Kapitel 8 verschiebt sich der Fokus hin zu einer höheren Ebene, und es werden drei Architektur-Patterns zum Strukturieren von Komponenten beschrieben.
• Kapitel 9 stellt die Patterns vor, die zum Orchestrieren der Arbeit der Systemkomponenten erforderlich sind.
• In Kapitel 10 werden die bisher besprochenen Patterns zu einer Handvoll einfacher Faustregeln zusammengeführt, die das Treffen von Designentscheidungen vereinfachen.
• Kapitel 11 schaut sich das Softwaredesign im zeitlichen Verlauf an und beschreibt, wie es sich im Rahmen seiner Lebensspanne verändern und weiterentwickeln sollte.
• Kapitel 12 stellt das EventStorming vor: ein Low-Tech-Workshop für das effektive Teilen von Wissen, den Aufbau eines gemeinsamen Verständnisses und das Designen von Software.
• Kapitel 13 führt die Schwierigkeiten auf, denen Sie sich eventuell gegenübersehen, wenn Sie Domain-Driven Design in bestehende Projekte einführen.
• In Kapitel 14 geht es um die Beziehung zwischen dem Microservices-Architekturstil und Domain-Driven Design: wo die Unterschiede liegen und wo sie sich gegenseitig ergänzen.
• Kapitel 15 schaut sich Patterns und Werkzeuge von Domain-Driven Design im Kontext der Event-Driven Architecture an.
• In Kapitel 16 wechseln wir schließlich noch von operationalen...