Domain Storytelling: Gemeinschaftlich, visuell und agil zu fachlich wertvoller Software

Von Stefan Hofer und Henning Schwentner

Fachliche Anforderungen in der Softwareentwicklung: Verstehen und verstanden werden

- fachliche motivierte Grenzen in Domänen finden, um Software und Teams danach zu organisieren
- Anforderungen aus Domain Stories ableiten
- Domain Storytelling mit Event Storming, User Story Mapping und anderen Methoden der agilen Softwareentwicklung kombinierenGeschichtenerzählen ist tief in der menschlichen Kommunikation verankert – das gilt auch im Zeitalter der Software. "Fachliche Geschichten" zu erzählen und zu visualisieren macht Geschäftsprozesse und Fachwissen greifbar.
Dieses Buch zeigt, wie Sie mit einfachen Mitteln fachlich stimmige Anwendungssoftware entwickeln können. Domain Storytelling hilft, das Fachwissen aus den Köpfen der Anwender*innen in die Köpfe von Entwickler*innen, Product Owners, Produktmanagement und Business Analysts zu transportieren. Es bringt die Beteiligten in Workshops zusammen, um sich über Aufgaben und Prozesse im Unternehmen abzustimmen. Das Ergebnis wird in einer einfachen Bildsprache dokumentiert.
Die Autoren erläutern an verständlichen Beispielen, wie Domain Storys entstehen und wie man Domain Storytelling für Domain-Driven Design, die Anforderungsermittlung und weitere Zwecke einsetzen kann.

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 29. Juni 2023
• ISBN: 9783988900197

Buchvorschau

Die Bildsprache

Die Bausteine werden verwendet, um die Sätze einer Domain Story zu bilden. Beispiel: Ein Kinomitarbeiter sagt: »Der Kinobesucher schaut einen Film an.« Wir zeichnen:

Stefan Hofer hat in Österreich Software Engineering studiert und einen Doktortitel in Informatik an der Universität Hamburg erworben. Seit 2005 arbeitet er für die WPS – Workplace Solutions GmbH. Requirements Engineering und Domain-Driven Design bilden seine Themenschwerpunkte. Stefan ist auf Mastodon (@[e-mail]), Twitter (@hofstef) und per E-Mail ([e-mail]) erreichbar.

Henning Schwentner beschäftigt sich mit Computern, seit er Anfang der 90er-Jahre einen Amiga 500 zum Geburtstag bekam. Er hatte das Glück, diese Leidenschaft zum Beruf zu machen, und arbeitet als Coder, Coach und Consultant bei WPS – Workplace Solutions. Er hilft Teams dabei, Struktur in ihre bestehende Software zu bringen oder neue Systeme mit einer nachhaltigen Architektur von Grund auf aufzubauen. Henning ist der Autor von Domain-Driven Transformation und LeasingNinja.io, der Übersetzer von Domain-Driven Design kompakt und Mitorganisator des ComoCamps. Er schreibt im Fediverse als @[e-mail], twittert als @hschwentner und liest E-Mails, die an [e-mail] gerichtet sind. Henning ist stolzer Vater von sechs Kindern in einer ganz besonderen Patchwork-Situation.

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Stefan Hofer · Henning Schwentner

Domain Storytelling

Gemeinschaftlich, visuell und agil

zu fachlich wertvoller Software

Stefan Hofer · [e-mail]

Henning Schwentner · [e-mail]

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz & Layout: Birgit Bäuerlein

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

1. Auflage 2023

Translation Copyright für die deutschsprachige Ausgabe © 2023

dpunkt.verlag GmbH

Wieblinger Weg 17· 69123 Heidelberg

Copyright der amerikanischen Originalausgabe © 2022 Pearson Education, Inc.

Titel der Originalausgabe: »Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software«. ISBN 978-0-13-745891-2. All rights reserved.

Glühbirnen-Icon: Irina Adamovich/Shutterstock

Auto-Icon: AF studio/Shutterstock

Häckchen-Icon: sudowoodo/123RF

Sonnenblumen-Icon: VECTOR ICONS/Shutterstock

Abbildung A–1: © Anita Krabbel

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [e-mail].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autoren noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Für unsere Familien.

Inhalt

Verzeichnis der Domain Stories

Geleitwort von Vaughn Vernon

Geleitwort von Nick Tune

Vorwort

Danksagung

Stimmen zu Domain Storytelling

Teil IDomain Storytelling – die Methode

1Einführung

1.1Was ist Domain Storytelling?

1.2Eine erste Domain Story

1.2.1Der Workshop beginnt

1.2.2Die Geschichte nacherzählen

1.2.3Die Domäne weiter erkunden

1.3Zusammenfassung und Ausblick

2Die Bildsprache

2.1Akteure

2.2Arbeitsgegenstände

2.3Aktivitäten

2.4Sequenznummern

2.5Notizen

2.6Modellierungsfläche

2.7Gruppierungen

2.8Farben

2.9Keine Fallunterscheidungen

2.10Die Bausteine im Zusammenspiel

2.11Eine Grammatik für Domain Stories

2.12Guter Stil

2.12.1In jedem Satz eigene Arbeitsgegenstände verwenden

2.12.2Arbeitsgegenstände explizit machen

2.12.3Jeden Baustein beschriften

2.12.4Unterschiedliche Icons für Akteure und Arbeitsgegenstände verwenden

2.12.5»Loopbacks« vermeiden

2.12.6Das »Anfrage und Antwort«-Muster vermeiden

3Szenariobasiertes Modellieren

3.1Was sind Szenarien?

3.2Szenarien im Domain Storytelling

3.3Konkrete Beispiele als Szenarien

3.4Den Überblick behalten

4Scope

4.1Granularität

4.2Zeitpunkt (IST vs. SOLL)

4.3Domain Purity (PUR vs. DIGITALISIERT)

4.4Die Scope-Faktoren kombinieren: eine exemplarische Abfolge

4.4.1Eine neue Domäne erkunden

(GROBGRANULAR, PUR, IST)

4.4.2Hineintauchen in Subdomänen

(FEINGRANULAR, PUR, IST)

4.4.3Neue Software einführen

(FEINGRANULAR, DIGITALISIERT, SOLL)

4.5Die Domain Stories im Überblick

5Modellierungswerkzeuge

5.1Modellieren auf Papier oder Tafeln

5.2Modellieren mit Softwarewerkzeugen

5.2.1Digitalisiertes händisches Zeichnen

5.2.2Universell einsetzbare Zeichenwerkzeuge

5.2.3Virtuelle Whiteboards

5.2.4Spezialisierte Modellierungswerkzeuge

5.3Ein Werkzeug auswählen

6Das Workshop-Format

6.1Vor dem Workshop

6.1.1Die richtigen Teilnehmer einladen

6.1.2Wie lange dauert ein Workshop?

6.1.3Vorbereiten des Raums

6.2Der Workshop

6.2.1Storytelling

6.2.2Die Geschichte visualisieren

6.2.3Wenn der Erzählfluss stockt

6.2.4Wenn die Geschichte zu lang wird

6.2.5Wie man eine gute Atmosphäre schafft

6.2.6Eine Domain Story abschließen

6.3Nach dem Workshop

6.4SOLL-Workshops

6.5Remote-Workshops

6.6Der Moderator

6.6.1Wer kann die Rolle einnehmen?

6.6.2Moderieren lernen

6.7Der Modellierer als eigenständige Rolle

6.8Moderierter Modus vs. kooperativer Modus

7Das Verhältnis zu anderen Modellierungsmethoden

7.1Domain-Driven Design

7.1.1Wie man DDD mit Domain Storytelling kombiniert

7.2Event Storming

7.2.1Gemeinsamkeiten und Unterschiede

7.2.2Wie man Event Storming mit Domain Storytelling kombiniert

7.3User Story Mapping

7.3.1Gemeinsamkeiten und Unterschiede

7.3.2Wie man User Story Mapping mit Domain Storytelling kombiniert

7.4Example Mapping

7.4.1Gemeinsamkeiten und Unterschiede

7.4.2Wie man Example Mapping mit Domain Storytelling kombiniert

7.5Storystorming

7.5.1Gemeinsamkeiten und Unterschiede

7.5.2Wie man Storystorming mit Domain Storytelling kombiniert

7.6Use Cases

7.6.1Gemeinsamkeiten und Unterschiede

7.6.2Wie man Use Cases mit Domain Storytelling kombiniert

7.7UML

7.7.1Gemeinsamkeiten und Unterschiede

7.7.2Wie man UML mit Domain Storytelling kombiniert

7.8BPMN

7.8.1Gemeinsamkeiten und Unterschiede

7.8.2Wie man BPMN mit Domain Storytelling kombiniert

7.9Zusammenfassung

Teil IIDomain Storytelling für verschiedene Einsatzzwecke nutzen und anpassen

8Fallstudie – Alphorn Auto Leasing GmbH

8.1Alphorn kennenlernen – die Domäne als Ganzes

8.2Risikobewertung vertiefen – eine wichtige Subdomäne verstehen

8.3Risikobewertung aufräumen – technischen Jargon vermeiden

8.4Optimieren der Risikobewertung – der SOLL-Prozess

8.5Neue Software einführen – Geschäftsprozesse mit IT unterstützen

8.6Zusammenfassung

9Fachsprache lernen

9.1Sprechen und Zuhören, um einander zu verstehen

9.1.1Glossare schreiben

9.1.2Hospitieren

9.1.3Können wir nicht einfach die Dokumentation lesen?

9.2Organisationen sprechen viele Fachsprachen

9.3Natürliche Sprachen verwenden

9.4Lost in Translation

9.5Was als Nächstes lesen?

10Grenzen finden

10.1Die Freude an mehreren Modellen

10.2Eine Heuristik zum Finden von Subdomänen

10.2.1Anwenden der Heuristik

10.2.2Indikatoren für Subdomänengrenzen

10.3Von Subdomänen zu Bounded Contexts

10.4Von Kontextgrenzen zu Teamgrenzen

10.5Was als Nächstes lesen?

11Mit Anforderungen arbeiten

11.1Softwareentwicklung als eine Folge von Gesprächen

11.2Von Domain Stories zu Anforderungen

11.2.1Ein Rezept zum Zerlegen einer Domain Story

11.2.2Anforderungen als User Stories aufschreiben

11.2.3Ein Backlog mit User Story Mapping strukturieren

11.3Das Rezept anpassen

11.4Einschränkungen

11.5Was als Nächstes lesen?

12Modellieren in Code

12.1Von Domain Stories zum Domänenmodell

12.1.1Szenarien verfeinern – von der Domain Story zum Akzeptanztest

12.2Implementieren des Domänenmodells

12.2.1Eine objektorientierte Implementierung nach DDD

12.2.2Eine funktionale Implementierung nach DDD

12.2.3Wenn ein einfacherer Stil ausreicht

12.3Was als Nächstes lesen?

13Organisatorische Veränderungen unterstützen

13.1Arbeitsabläufe von Menschen ändern

13.1.1Den Wandel modellieren

13.2Arbeit digitalisieren

13.2.1Entwerfen tragfähiger softwaregestützter Prozesse

13.3Was als Nächstes lesen?

14»Make or Buy«-Entscheidungen und Auswahl von Standardsoftware

14.1Die Prozesse von Standardsoftware verstehen

14.2Was als Nächstes lesen?

15Schatten-IT finden

15.1Nicht nur Softwareentwickler entwickeln Software

15.2Versteckte Softwaresysteme sichtbar machen

15.3Was als Nächstes lesen?

16Ausblick und Fazit

16.1Die Zukunft von Domain Storytelling

16.2Die Essenz von Domain Storytelling

Anhang

ADie Geschichte von Domain Storytelling

BGlossar

CLiteratur

Index

Verzeichnis der Domain Stories

Geleitwort von Vaughn Vernon

In meiner »Signature Series«¹ stehen organisches Wachstum und Weiterentwicklung im Vordergrund, die ich im Folgenden genauer beschreibe. Doch zuerst erzähle ich eine Geschichte vom organischen Wachstum, die mit diesem Buch verbunden ist.

Mein Buch Implementing Domain-Driven Design, auch bekannt als »das rote Buch«, erschien zu einem wichtigen Zeitpunkt. Vor dem roten Buch gab es nur eine Handvoll Menschen, die Domain-Driven Design (DDD), diesen fortschrittlichen Ansatz zur Softwareentwicklung, wirklich verstanden hatten – diejenigen, die man als Vorreiter bezeichnen könnte. Außerdem gab es zu dieser Zeit nur wenige DDD-Meetups und kaum hilfreiche Werkzeuge, die Praktiker bei der Anwendung von DDD unterstützten. Ich war Mitbegründer des DDD-Meetup in Denver im Jahr 2011, lange bevor mein rotes Buch 2013 veröffentlicht wurde. Damals gab es vielleicht insgesamt fünf Meetups zu diesem Thema. Im Jahr 2021 konnte man weltweit 142 Meetup-Gruppen zu DDD mit 93.171 Mitgliedern finden, und es werden immer mehr. Als zunächst 10, dann 20 und dann 25 Gruppen erreicht waren, hätte da jemand gedacht, dass es einmal fast 150 sein würden? Infolge dieses organischen Wachstums wuchs auch die Zahl der Vorreiter und der Werkzeuge für DDD. Timing ist alles, und ich freue mich, dass ich zu den richtigen Zeitpunkten Impulse geben konnte, die zur Verbreitung von DDD beigetragen haben. Bevor ich erkläre, wie dieses Buch und seine Autoren an diesem organischen Wachstum beteiligt sind, möchte ich zunächst auf die Reihe eingehen, in der es erscheint.

Meine »Signature Series« verhilft den Leserinnen und Lesern zu Fortschritten in der Reife der Softwareentwicklung und führt sie zur erfolgreichen Anwendung geschäftsorientierter Praktiken. Die Reihe legt den Schwerpunkt auf organisches Wachstum und Weiterentwicklung mit einer Vielzahl von Ansätzen – reaktive, objektorientierte und funktionale Architektur und Programmierung, Domänenmodellierung, Services in der richtigen Größe, Patterns und APIs – und behandelt die beste Nutzung der zugrunde liegenden Technologien.

Ab hier konzentriere ich mich auf nur zwei Wörter: organische Weiterentwicklung.

Das erste Wort, organisch, benutzte ein Freund und Kollege kürzlich, um Softwarearchitektur zu beschreiben. Ich habe das Wort organisch schon oft im Zusammenhang mit Softwareentwicklung gehört und verwendet, aber ich habe nicht so genau darüber nachgedacht, bis ich die beiden Wörter zusammen gehört habe: organische Architektur.

Man denke an die Wörter organisch und Organismus. Meistens werden sie im Zusammenhang mit Lebewesen verwendet, aber auch, um unbelebte Dinge zu beschreiben, die in einigen Eigenschaften Lebewesen ähneln. Der Begriff Organismus stammt aus dem Griechischen. Etymologisch bezieht er sich auf einen Teil eines lebendigen Ganzen, hat aber noch weitere Bedeutungen: ein Mittel zur Herstellung von etwas im Sinne von Gerät, (Musik-)Instrument oder Werkzeug.

Es fällt uns nicht schwer, uns Beispiele für organische Objekte im Sinne von lebenden Organismen vorzustellen von den ganz großen bis zu mikroskopisch kleinen, einzelligen Lebensformen. Bei der zweiten Verwendung von Organismus müssen wir schon etwas länger nachdenken. Ein Beispiel ist eine Organisation, die mit dem gleichen Präfix wie organisch und Organismus beginnt. In dieser Bedeutung beschreibt Organismus etwas mit bidirektionalen Abhängigkeiten: Eine Organisation ist ein Organismus, weil sie organisierte Teile hat. Diese Art von Organismus kann ohne die Teile nicht überleben, und die Teile können ohne den Organismus nicht überleben.

Diese Denkweise können wir auch auf unbelebte Dinge anwenden, denn sie weisen Eigenschaften von lebenden Organismen auf. Nehmen wir z.B. das Atom. Jedes einzelne Atom ist ein System für sich, und alle Lebewesen bestehen aus Atomen. Die Atome selbst sind jedoch anorganisch und vermehren sich nicht. Trotzdem kann man sich Atome als Lebewesen in dem Sinne vorstellen, dass sie sich ständig bewegen und aktiv sind. Atome gehen sogar Verbindungen mit anderen Atomen ein. Wenn dies geschieht, ist jedes Atom nicht nur ein einzelnes System für sich, sondern wird zusammen mit anderen Systemen auch zu einem Subsystem. Zusammen mit anderen solchen Subsystemen ergibt deren gemeinsames Verhalten ein größeres Gesamtsystem.

Alle Konzepte, die sich auf Software beziehen, sind also insofern organisch, als nicht lebende Dinge durch Aspekte lebender Organismen »charakterisiert« werden. Wenn wir softwaretechnische Modelle anhand konkreter Szenarien diskutieren, ein Architekturdiagramm zeichnen oder einen Unit Test und die dazugehörige fachliche »Unit« programmieren, beginnt die Software lebendig zu werden. Sie ist nicht statisch, denn wir diskutieren immer wieder über Verbesserungen und entwickeln sie weiter, wobei ein Szenario zum nächsten führt, was sich wiederum auf die Architektur und das Domänenmodell auswirkt. Wenn wir weiter iterieren, führt der steigende Wert der Weiterentwicklungen zu einem inkrementellen Wachstum des Organismus. Mit der Zeit entwickelt sich die Software weiter. Wir kämpfen mit der Komplexität und bewältigen sie durch nützliche Abstraktionen, und die Software wächst und verändert ihre Form, alles mit dem ausdrücklichen Ziel, die Arbeit für echte, lebende Organismen auf globaler Ebene zu verbessern.

Leider tendieren Softwareorganismen dazu, eher schlecht als gut zu wachsen. Selbst wenn sie ihr Leben bei guter Gesundheit beginnen, neigen sie dazu, Krankheiten zu bekommen, sich zu verformen, unnatürliche Auswüchse zu entwickeln, zu verkümmern und zu verfallen. Noch schlimmer ist, dass diese Symptome durch gut gemeintes, aber schiefgegangenes Verfeinern verursacht werden. Das Schlimmste daran ist, dass die fehlgeschlagene Weiterentwicklung nicht zum Tod dieser auf komplexe Art kranken Softwareorganismen führt. (Oh, wenn sie doch nur sterben könnten!) Stattdessen müssen wir sie töten, und das erfordert Nerven, Geschick und das Durchhaltevermögen eines Drachentöters. Nein, nicht eines, sondern Dutzender von kräftigen Drachentötern. Oder besser gesagt: Dutzende von Drachentötern mit richtig viel Verstand.

Genau hier kommt diese Buchreihe ins Spiel. Sie soll ihnen dabei helfen, sich weiterzuentwickeln und mit verschiedenen Ansätzen – reaktive, objektorientierte und funktionale Architektur und Programmierung, Domänenmodellierung, Services in der richtigen Größe, Muster und APIs – erfolgreich zu sein. Außerdem deckt die Buchreihe die optimale Nutzung der zugrunde liegenden Technologien ab. Das ist nicht mit einem Schlag erledigt. Es erfordert eine organische Weiterentwicklung mit Engagement und Geschick. Die anderen Autoren und ich sind da, um zu helfen. Zu diesem Zweck haben wir unser Bestes gegeben, um unser Ziel zu erreichen.

Deshalb habe ich dieses Buch, Domain Storytelling, ausgewählt, um es in meine Signature Series aufzunehmen. Die bereits erwähnte organische Ausbreitung von DDD hat zu neuen Praktikern und Vorreitern sowie zu Innovationen bei