Gerade in den letzten Jahren hat Domain-Driven Design – nicht zuletzt durch seine gute Einsetzbarkeit im Zusammenhang mit Microservices – enorm an Bekanntheit gewonnen. Doch nicht jeder weiß vermutlich, wie DDD in seinen Anfängen ausgesehen hat. Wo hat das Ganze angefangen, und wie hat es sich im Laufe der Zeit verändert? Was ist neu hinzugekommen, was ist verschwunden, und was hat auch nach 20 Jahren noch Bestand? Und wo kann die Reise möglicherweise hingehen? Fragen dieser und ähnlicher Natur werden in diesem Vortrag aufgeworfen und beleuchtet.

Event Storming ist eine Methode des Domain-Driven Design, die es ermöglicht, sich gemeinsam die Fachlichkeit einer Anwendung zu erarbeiten. In diesem Vortrag werden wir uns mit den Grundlagen des Event Storming und den Einflussfaktoren für eine effektive Durchführung beschäftigen. Wer sind die Teilnehmer? Wie viel Zeit sollte ich einplanen? Welche Flughöhe ist die richtige für eine wertstiftende Diskussion, bei der am Ende alle mit einem gemeinsamen Verständnis über die Fachdomäne rausgehen. Richtig angewendet und bis zum Ende durchgeführt, bietet Event Storming unglaublich viel. Das Ergebnis kann sowohl für UX-Entscheidungen als auch für einen guten Softwareschnitt verwendet werden. Auf diese Aspekte und meine Erfahrungen damit werde ich eingehen.
 

Wie man ein neues Projekt auf der grünen Wiese beginnt und dabei eine saubere Architektur baut, das wissen wir heute ganz gut. Aber die meisten von uns arbeiten ja in Projekten, die schon lange da sind und deren Architektur (vorsichtig gesagt) nicht mehr ganz so schön ist. "Monolith" und "Big Ball of Mud" sind die wenig schmeichelhaften Titel, die solchen Systemen verpasst werden.

In diesem Talk zeige ich, wie wir hier (wieder) Struktur einführen können. Jedes System ist hier anders, deswegen ist es wichtig, zunächst zu erkennen, wo man steht. Dann müssen die richtigen Schritte unternommen werden. Ich präsentiere außerdem einen Katalog von Refactorings, aus denen man wählen kann, und Heuristiken, was die richtige Wahl ist.

Beim Analysieren und Zerlegen von Legacy-Systemen nach DDD sind wir auf Domänen gestoßen, die einfach in Subdomänen aufgeteilt werden konnten, und auf Domänen, bei denen es deutlich schwieriger war. Auch das Alter und der Entwicklungsgrad einer Domäne haben Einfluss auf unsere Möglichkeiten, gute Subdomänen zu finden und die Legacy zu modularisieren. Inzwischen können wir diese Unterschiede beschreiben und haben verschiedene Domain Patterns gefunden und benannt. Ich freue mich auf Feedback und Diskussionen von den Zuhörer:innen.

Gefühlt stand das Akronym WWW lange Zeit eher für Wild Wild West. Architekturmuster und -Prinzipien waren im Frontend oft die Ausnahme. Erst mit der letzten großen Frameworkwelle und dem Siegeszug von SPAs begann ein längst notwendiges Umdenken.

Neuere Technologien führen aber nicht automatisch zu einer besseren Architektur. Es gilt, nach wie vor, Architekturmuster gezielt einzusetzen. Eines der bekanntesten Muster im Domain-Driven Design ist die hexagonale Architektur. Wann lohnt sich der Einsatz und wie funktioniert das in der Praxis?

Was bedeutet es eigentlich, Domain-driven Design (DDD) umzusetzen? Dieser Vortrag führt durch ein vollständiges Beispiel und zeigt, wie die verschiedenen Techniken wie Event Storming, strategisches Design und taktisches Design zusammenwirken, um den Aufbau von Anwendungen zu unterstützen. Auf diese Weise bekommen die Teilnehmer praktische Hinweise, wie sie mit einem einfachen, aber vollständigen Ansatz mit DDD beginnen können.

Gute Business-Software muss auf die Fachlichkeit und die Aufgaben der Anwender:innen zugeschnitten sein. Deswegen müssen alle Rollen, die an der Softwareentwicklung beteiligt sind, die Domäne verstehen und die Sprache des Fachbereichs sprechen: Entwickler:innen, Tester:innen, Product Owner, Projektmanager:innen und Anforderungsermittler:innen. Mit Hilfe von Domain Storytelling kann man dieses gemeinsame Verständnis aufbauen.

Domain Storytelling bedeutet, dass Fachexpert:innen Geschichten über ihre Domäne erzählen. Während wir zuhören, zeichnen wir die Domain Stories vor den Augen der Fachexpert:innen mit einer Bildsprache auf. Dadurch können alle Beteiligten unmittelbar sehen, ob sie richtig verstanden wurde. Schon nach wenigen Domain Stories haben wir die wesentlichen Konzepte einer Domäne herausgearbeitet: Akteur:innen, ihre Aufgaben, ihre Werkzeuge (z.B. IT-Systeme und Apps) und die bearbeiteten Arbeitsgegenstände (z.B. Dokumente).

Wozu kann ich Domain Storytelling einsetzen?

• Als Einstieg in eine neue Domäne: Fachsprache erarbeiten, Arbeitsabläufe verstehen
• Fachliche "Silos" überbrücken durch gemeinschaftliches Modellieren
• Fachliche Schnitte für Software finden: Heuristiken für guten Schnitt von Modulen, Microservices und Bounded Contexts
• Soll-Prozesse entwerfen: Arbeitsabläufe und Softwareentwicklung aufeinander abstimmen, Veränderungen vom Ist zum Soll transparent machen
• Anforderungen identifizieren: durch direktes Ableiten aus den Domain Stories
• Minimum Viable Products definieren durch Reduzierung der IT-gestützten Prozesse auf das Wesentliche
• Nach dem Training können die Teilnehmer:innen eigenständig Domain Storytelling anwenden. Sie erhalten außerdem ein Exemplar des "Domain Storytelling"-Buchs

Voraussetzungen: Keine. Das Training eignet sich auch für nichttechnische Rollen wie Product Owner.
Maximal 12 Teilnehmende