Domain Storytelling

Name: Domain Storytelling | Gemeinschaftlich, visuell und agil zu fachlich wertvoller Software
Brand: dpunkt
Price: 34.9 EUR
Availability: OnlineOnly

Gemeinschaftlich, visuell und agil zu fachlich wertvoller Software

Stefan Hofer Henning Schwentner(Autor*in)

dpunkt (Verlag)

1. Auflage

Erschienen am 29. Juni 2023

256 Seiten

E-Book

PDF mit Wasserzeichen-DRM

Systemvoraussetzungen

978-3-98890-018-0 (ISBN)

34,90 €inkl. 7% MwSt.

Systemvoraussetzungen

für PDF mit Wasserzeichen-DRM

E-Book Einzellizenz

Als Download verfügbar

Beschreibung

Weitere Details

Weitere Ausgaben

Personen

Inhalt

Intro
U2 - Die Bildsprache
Domain Storytelling
Inhalt
Verzeichnis der Domain Stories
Geleitwort von Vaughn Vernon
Geleitwort von Nick Tune
Vorwort
Tab. 1 In »Opening Stories« verwendete Icons
Danksagung
Stimmen zu Domain Storytelling
Teil I - Domain Storytelling - die Methode
1 Einführung
1.1 Was ist Domain Storytelling?
1.2 Eine erste Domain Story
1.2.1 Der Workshop beginnt
Abb. 1-1 Der erste Akteur
Abb. 1-2 Der zweite Akteur und die erste Notiz
Abb. 1-3 Die erste Aktivität
Abb. 1-4 Die zweite Aktivität
Abb. 1-5 Die dritte Aktivität
Abb. 1-6 Die vierte Aktivität
1.2.2 Die Geschichte nacherzählen
Abb. 1-7 Die ganze Geschichte
Abb. 1-8 Hinzufügen einer weiteren Notiz
1.2.3 Die Domäne weiter erkunden
Abb. 1-9 Metropolis 1: Ins Kino gehen - grobgranular
1.3 Zusammenfassung und Ausblick
Abb. 1-10 Metropolis 2: Kartenverkauf, Happy Path - feingranular
2 Die Bildsprache
2.1 Akteure
Abb. 2-1 Typische Akteure
2.2 Arbeitsgegenstände
Abb. 2-2 Typische Arbeitsgegenstände. Beachte: »Kinokarte« und »Preis« erscheinen jeweils zweimal mit unterschiedlichen Icons.
Abb. 2-3 Icon-Set für die Domäne »Kino«
2.3 Aktivitäten
Abb. 2-4 Typische Aktivitäten
2.4 Sequenznummern
Abb. 2-5 Typische Sequenznummern
2.5 Notizen
Abb. 2-6 Typische Notizen
2.6 Modellierungs äche
Abb. 2-7 Typisches Layout der Modellierungs äche
Abb. 2-8 Beispiel für das Layout einer Modellierungs äche auf einem Whiteboard
2.7 Gruppierungen
Abb. 2-9 Eine typische Gruppierung
Abb. 2-10 Metropolis 1a: Ins Kino gehen - grobgranular - gruppiert nach Subdomänen
2.8 Farben
Abb. 2-11 Typische Verwendung von Farben
Abb. 2-12 Metropolis 1b: Ins Kino gehen - grobgranular - Farben zeigen gesetzliche Bestimmungen
2.9 Keine Fallunterscheidungen
Abb. 2-13 Der klassische (Nicht-Domain-Storytelling-)Ansatz: Modellierung verschiedener Fälle in einem Diagramm (hier: ein Kontroll uss mit vier Gateways, modelliert in BPMN)
2.10 Die Bausteine im Zusammenspiel
Abb. 2-14 Ein Arbeitsgegenstand ändert seine Erscheinungsform.
2.11 Eine Grammatik für Domain Stories
Abb. 2-15 Mögliche Satzkonstruktionen
Abb. 2-16 Unterschiedlicher Stil, gleiche Bedeutung: handgezeichnet vs. werkzeuggezeichnet
2.12 Guter Stil
2.12.1 In jedem Satz eigene Arbeitsgegenstände verwenden
2.12.2 Arbeitsgegenstände explizit machen
Abb. 2-17 Don't: Arbeitsgegenstände als Teil der Aktivität modellieren
Abb. 2-18 Do: Arbeitsgegenstand getrennt von der Aktivität modellieren
Abb. 2-19 Don't: Arbeitsgegenstand als Teil eines anderen Arbeitsgegenstandes modellieren
2.12.3 Jeden Baustein beschriften
2.12.4 Unterschiedliche Icons für Akteure und Arbeitsgegenstände verwenden
2.12.5 »Loopbacks« vermeiden
Abb. 2-20 Don't: Funktionsaufruf modellieren
Abb. 2-21 Do: Aktivität modellieren
2.12.6 Das »Anfrage und Antwort«-Muster vermeiden
Abb. 2-22 Don't: technische Details modellieren, wie ein Nutzer mit einem System interagiert
Abb. 2-23 Do: modellieren, was der Benutzer erreichen will
3 Szenariobasiertes Modellieren
3.1 Was sind Szenarien?
Abb. 3-1 Ein Szenario ist ein konkreter Fall eines Geschäftsprozesses.
Abb. 3-2 Eine Reise durch Europa als Beispiel für ein Szenario (das Bild stammt von OpenStreetMap.org)
3.2 Szenarien im Domain Storytelling
Abb. 3-3 Metropolis 3: Kartenverkauf, Vorstellung ist ausverkauft - feingranular
Abb. 3-4 Der Domain-Storytelling-Ansatz: Modellieren verschiedener Fälle in verschiedenen Domain Stories: Metropolis 2 und 3
3.3 Konkrete Beispiele als Szenarien
3.4 Den Überblick behalten
Abb. 3-5 Anwendungsfalldiagramm für Metropolis
4 Scope
4.1 Granularität
Abb. 4-1 Von Metropolis 1a zu Metropolis 2: Eine Aktivität aus einer grobgranularen Story wird detailliert in einer feingranularen Story.
Abb. 4-2 Verschiedene Goal Levels
4.2 Zeitpunkt (ist vs. soll)
Abb. 4-3 Der Scope-Faktor Zeitpunkt
Abb. 4-4 Beispiel für den Zeitpunkt einer Domain Story
4.3 Domain Purity (pur vs. digitalisiert)
Abb. 4-5 Domain Stories mit Softwaresystemen als Akteure werden als digitalisiert bezeichnet.
4.4 Die Scope-Faktoren kombinieren: eine exemplarische Abfolge
4.4.1 Eine neue Domäne erkunden (grobgranular, pur, ist)
4.4.2 Hineintauchen in Subdomänen (feingranular, pur, ist)
4.4.3 Neue Software einführen (feingranular, digitalisiert, soll)
Abb. 4-6 Metropolis 4: Kartenverkauf, Happy Path - feingranular, digitalisiert, soll
4.5 Die Domain Stories im Überblick
Tab. 4-1 Überblick über die Metropolis Domain Stories
5 Modellierungswerkzeuge
5.1 Modellieren auf Papier oder Tafeln
Abb. 5-1 Modellieren auf Papier
Abb. 5-2 Klebezettel auf dem Whiteboard
Abb. 5-3 Arbeitsgegenstände auf quadratische Klebezettel zeichnen
Abb. 5-4 Akteure auf rechteckige Klebezettel zeichnen
Abb. 5-5 Magnetisches, laminiertes Whiteboard-Kit
5.2 Modellieren mit Softwarewerkzeugen
5.2.1 Digitalisiertes händisches Zeichnen
Abb. 5-6 Domain Storytelling mit einer digitalen Tafel
5.2.2 Universell einsetzbare Zeichenwerkzeuge
Abb. 5-7 Modellieren mit diagrams.net
5.2.3 Virtuelle Whiteboards
Abb. 5-8 Metropolis 2 ohne Icons auf einem digitalen Whiteboard
Abb. 5-9 Ein Vorschlag, wie man Icons in Miro verwenden kann
Abb. 5-10 Werkzeuge kombinieren - eine Domain Story, die in Egon.io modelliert wurde, mit Gruppierungen, gezeichnet in Miro
5.2.4 Spezialisierte Modellierungswerkzeuge
Abb. 5-11 Modellieren von Metropolis 2 mit Egon.io
5.3 Ein Werkzeug auswählen
Tab. 5-1 Vergleich von Modellierungswerkzeugen
6 Das Workshop-Format
6.1 Vor dem Workshop
6.1.1 Die richtigen Teilnehmer einladen
6.1.2 Wie lange dauert ein Workshop?
6.1.3 Vorbereiten des Raums
Abb. 6-1 Der Stonehenge-Aufbau
6.2 Der Workshop
6.2.1 Storytelling
6.2.2 Die Geschichte visualisieren
Abb. 6-2 Don't: Handlungslöcher zwischen den Sätzen einer Domain Story lassen
6.2.3 Wenn der Erzähl uss stockt
6.2.4 Wenn die Geschichte zu lang wird
Abb. 6-3 Zu lang für Bücher und Präsentationen: Metropolis 5
6.2.5 Wie man eine gute Atmosphäre scha t
6.2.6 Eine Domain Story abschließen
6.3 Nach dem Workshop
6.4 Soll-Workshops
6.5 Remote-Workshops
6.6 Der Moderator
6.6.1 Wer kann die Rolle einnehmen?
6.6.2 Moderieren lernen
6.7 Der Modellierer als eigenständige Rolle
6.8 Moderierter Modus vs. kooperativer Modus
7 Das Verhältnis zu anderen Modellierungsmethoden
7.1 Domain-Driven Design
7.1.1 Wie man DDD mit Domain Storytelling kombiniert
7.2 Event Storming
Abb. 7-1 Big Picture Event Storming im Metropolis
7.2.1 Gemeinsamkeiten und Unterschiede
7.2.2 Wie man Event Storming mit Domain Storytelling kombiniert
Von Event Storming zu Domain Storytelling
Von Domain Storytelling zu Event Storming
7.3 User Story Mapping
Abb. 7-2 Eine User Story Map für die Metropolis-Kinokassen-App
7.3.1 Gemeinsamkeiten und Unterschiede
7.3.2 Wie man User Story Mapping mit Domain Storytelling kombiniert
7.4 Example Mapping
Abb. 7-3 Example Map für die Metropolis-Kinokassen-App
7.4.1 Gemeinsamkeiten und Unterschiede
7.4.2 Wie man Example Mapping mit Domain Storytelling kombiniert
7.5 Storystorming
7.5.1 Gemeinsamkeiten und Unterschiede
Abb. 7-4 Metropolis 1 in Storystorming-Notation
Abb. 7-5 Legende für Storystorming
7.5.2 Wie man Storystorming mit Domain Storytelling kombiniert
7.6 Use Cases
7.6.1 Gemeinsamkeiten und Unterschiede
7.6.2 Wie man Use Cases mit Domain Storytelling kombiniert
7.7 UML
7.7.1 Gemeinsamkeiten und Unterschiede
7.7.2 Wie man UML mit Domain Storytelling kombiniert
7.8 BPMN
7.8.1 Gemeinsamkeiten und Unterschiede
7.8.2 Wie man BPMN mit Domain Storytelling kombiniert
7.9 Zusammenfassung
Teil II - Domain Storytelling für verschiedene Einsatzzwecke nutzen und anpassen
8 Fallstudie - Alphorn Auto Leasing GmbH
8.1 Alphorn kennenlernen - die Domäne als Ganzes
Abb. 8-1 Alphorn 1: Ein Auto leasen - grobgranular, pur, ist
8.2 Risikobewertung vertiefen - eine wichtige Subdomäne verstehen
Abb. 8-2 Alphorn 2: Risikobewertung - feingranular, digitalisiert, ist
8.3 Risikobewertung aufräumen - technischen Jargon vermeiden
Abb. 8-3 Alphorn 3: Risikobewertung - feingranular, pur, ist
8.4 Optimieren der Risikobewertung - der Soll-Prozess
Abb. 8-4 Alphorn 4: Risikobewertung - feingranular, pur, soll
8.5 Neue Software einführen - Geschäftsprozesse mit IT unterstützen
Abb. 8-5 Alphorn 5: Risikobewertung - feingranular, digitalisiert, soll
8.6 Zusammenfassung
Tab. 8-1 Überblick über die Domain Stories für die Alphorn Auto Leasing GmbH
Tab. 8-2 Das Icon-Set für die Alphorn Auto Leasing GmbH
9 Fachsprache lernen
9.1 Sprechen und Zuhören, um einander zu verstehen
Abb. 9-1 Alphorn 4: Risikobewertung - feingranular, pur, soll
Abb. 9-2 De nition eines Fachbegri es
9.1.1 Glossare schreiben
Abb. 9-3 Ein Glossar auf Klebezetteln
Tab. 9-1 Auszug aus dem Risikomanagementglossar
9.1.2 Hospitieren
9.1.3 Können wir nicht einfach die Dokumentation lesen?
9.2 Organisationen sprechen viele Fachsprachen
9.3 Natürliche Sprachen verwenden
Abb. 9-4 Auf Englisch: Reisen mit dem Taxi
Abb. 9-5 Auf Persisch: Reisen mit dem Flugzeug
Abb. 9-6 Auf Chinesisch: Reisen mit dem Zug
9.4 Lost in Translation
9.5 Was als Nächstes lesen?
10 Grenzen nden
10.1 Die Freude an mehreren Modellen
10.2 Eine Heuristik zum Finden von Subdomänen
10.2.1 Anwenden der Heuristik
Abb. 10-1 Alphorn 1: Ein Auto leasen - grobgranular, pur, ist
Abb. 10-2 Die Subdomäne »Vertragsabschluss«
Abb. 10-3 Die Subdomäne »Risikobewertung«
Abb. 10-4 Alphorn 1a: Ein Auto leasen - grobgranular, pur, ist - gruppiert nach Subdomänen
10.2.2 Indikatoren für Subdomänengrenzen
Abb. 10-5 Indikator: Unterschiedliche Auslöser - hier: zeitlicher Rhythmus
10.3 Von Subdomänen zu Bounded Contexts
Abb. 10-6 Anfang einer Context Map für Alphorn
10.4 Von Kontextgrenzen zu Teamgrenzen
Abb. 10-7 Teamorganisation bei Alphorn
10.5 Was als Nächstes lesen?
11 Mit Anforderungen arbeiten
11.1 Softwareentwicklung als eine Folge von Gesprächen
Abb. 11-1 Verschiedene Goal Levels
11.2 Von Domain Stories zu Anforderungen
11.2.1 Ein Rezept zum Zerlegen einer Domain Story
11.2.2 Anforderungen als User Stories aufschreiben
11.2.3 Ein Backlog mit User Story Mapping strukturieren
Abb. 11-2 Der Bounded Context »Vertragsabschluss« aus Alphorn 1a
Abb. 11-3 Eine Anforderung auf Kite Level für unsere User Story Map
Abb. 11-4 Backbone von Anforderungen auf Kite Level
Abb. 11-5 Alphorn 6: Vertragsabschluss, Happy Path - feingranular
Abb. 11-6 Alphorn 7: Vertragsabschluss, Ablehnung - feingranular
Abb. 11-7 Backbone für den Kontext »Vertragsabschluss«
Abb. 11-8 Product Backlog für den Bounded Context »Vertragsabschluss«
11.3 Das Rezept anpassen
11.4 Einschränkungen
11.5 Was als Nächstes lesen?
12 Modellieren in Code
12.1 Von Domain Stories zum Domänenmodell
Abb. 12-1 Schlecht: ein anämisches Domänenmodell
Abb. 12-2 Alphorn 1a: Leasing-Subdomänen - mit Fokus auf »Vertragsabschluss«
Abb. 12-3 Alphorn 6: Vertragsabschluss, Happy Path - feingranular
Abb. 12-4 Alphorn 7: Vertragsabschluss, Ablehnung - feingranular
12.1.1 Szenarien verfeinern - von der Domain Story zum Akzeptanztest
12.2 Implementieren des Domänenmodells
12.2.1 Eine objektorientierte Implementierung nach DDD
Abb. 12-5 Entity Vertrag
Abb. 12-6 Entity Vertrag mit Methoden
Abb. 12-7 Von der Domain Story zum Klassendiagramm
Abb. 12-8 Entity Vertrag mit Value Objects
Abb. 12-9 Entity Vertrag als Zustandsautomat
12.2.2 Eine funktionale Implementierung nach DDD
12.2.3 Wenn ein einfacherer Stil ausreicht
12.3 Was als Nächstes lesen?
13 Organisatorische Veränderungen unterstützen
13.1 Arbeitsabläufe von Menschen ändern
13.1.1 Den Wandel modellieren
Abb. 13-1 Veränderung visualisieren - eine typische Legende
Abb. 13-2 Alphorn 3a: Risikobewertung - feingranular, pur, ist - eingefärbt
Abb. 13-3 Alphorn 4a: Risikobewertung - feingranular, pur, soll - eingefärbt
Abb. 13-4 Alphorn 3b: Risikobewertung - feingranular, pur, ist - gruppiert
Abb. 13-5 Alphorn 4b: Risikobewertung - feingranular, pur, soll - gruppiert
13.2 Arbeit digitalisieren
13.2.1 Entwerfen tragfähiger softwaregestützter Prozesse
Abb. 13-6 Alphorn 2a: Risikobewertung - feingranular, digitalisiert, ist - eingefärbt
Abb. 13-7 Alphorn 5a: Risikobewertung - feingranular, digitalisiert, soll - eingefärbt
13.3 Was als Nächstes lesen?
14 »Make or Buy«-Entscheidungen und Auswahl von Standardsoftware
14.1 Die Prozesse von Standardsoftware verstehen
Abb. 14-1 Context Map für Alphorn, Fokus auf »Zahlung«
Abb. 14-2 Alphorn 8: Zahlung, Standardfall - pur
Abb. 14-3 Alphorn 9: Zahlung, fehlende Zahlung - pur
Abb. 14-4 Alphorn 8a: Zahlung, Standardfall - digitalisiert - mit System Paynator
Abb. 14-5 Alphorn 8b: Zahlung, Standardfall - digitalisiert - mit System GreatPay
Abb. 14-6 Alphorn 9a: Zahlung, fehlende Zahlung - digitalisiert - mit System Paynator
Abb. 14-7 Alphorn 9b: Zahlung, fehlende Zahlung - digitalisiert - mit System GreatPay
14.2 Was als Nächstes lesen?
15 Schatten-IT nden
15.1 Nicht nur Softwareentwickler entwickeln Software
15.2 Versteckte Softwaresysteme sichtbar machen
Abb. 15-1 Alphorn 4: Risikobewertung - feingranular, pur, soll
Abb. 15-2 Alphorn 9: Zahlung, fehlende Zahlung - pur
Abb. 15-3 Alphorn 10: Nachverfolgung der ausbleibenden Zahlungen - digitalisiert, ist
15.3 Was als Nächstes lesen?
16 Ausblick und Fazit
16.1 Die Zukunft von Domain Storytelling
16.2 Die Essenz von Domain Storytelling
Anhang
A Die Geschichte von Domain Storytelling
Abb. A-1 Ein Vorfahre von Domain Storytelling: Kooperationsbilder
Abb. A-2 Eines der ersten szenariobasierten Kooperationsbilder
Abb. A-3 Ein Kooperationsszenario mit Werkzeugunterstützung modelliert
B Glossar
C Literatur
Index
U3 - Typische Satzkonstruktionen

Systemvoraussetzungen

Als PDF speichern Als Link merken