Wie Entwickler und Fachexperten gemeinsam Domain-driven-Software entwickeln

Mehr Verständnis füreinander

Mehr Verständnis füreinander

Wie Entwickler und Fachexperten gemeinsam Domain-driven-Software entwickeln

Mehr Verständnis füreinander


Wir zeigen, warum man Collaborative Modeling (CoMo) braucht, und beschreiben den gemeinsamen Kern verschiedener CoMo-Methoden. Vier solche Methoden stellen wir vor und geben Handlungsanleitungen: Welches Problem lässt sich mit welcher Methode anpacken und wie kombiniere ich Methoden sinnvoll in einem agilen Entwicklungsprozess?

Gemeinsam mit allen Beteiligten Anwendungssoftware zu entwickeln – das charakterisiert agile Softwareentwicklung im Allgemeinen und Methoden der Softwareentwicklung wie Domain-driven Design (DDD) und Behaviour-driven Design (BDD) im Besonderen. Es ist ein großer Schritt in die richtige Richtung, verglichen mit dem früher üblichen „Über-den-Zaun-werfen“ von Spezifikationsdokumenten. Doch im konkreten Projekt benötigen wir zusätzlich zu Agile und DDD noch Techniken, um das fachliche Verständnis unter den Beteiligten einfach und schnell zu erreichen und festzuhalten. Diese Vorgehensweisen mit den dahinterstehenden Ideen und Konzepte fassen wir unter dem Etikett Collaborative Modeling zusammen.

Weshalb Collaborative Modeling?

CoMo steht hinter vielen erfolgreichen Methoden, die traditionell unter „Anforderungsermittlung“ fallen würden. Denn die IT-Experten müssen die Domäne, also die Aufgaben und Arbeitsabläufe der AnwenderInnen, verstehen, um eine gute Anwendung entwickeln zu können. Umgekehrt sollen Fachexperten und Anwender verstehen, welche Möglichkeiten durch Software geschaffen werden und welche Auswirkungen die Digitalisierung auf ihre tägliche Arbeit haben wird. Entwickler und Fachexperten benötigen eine gemeinsame Sprache, um über die Domäne und die daraus erwachsenden Anforderungen an die Software sprechen zu können. Nur so wird die Software das widerspiegeln, was die Entwickler von den Anforderungen aus der Domäne verstanden haben und was Anwender und Fachexperten von einer Digitalisierung der fachlichen Prozesse erwarten. CoMo soll das Fachwissen aus den Köpfen der Anwender in die Köpfe von Entwicklern, Testern, Product Owners, Produktmanagern, Businessanalysten etc. transportieren – also zu jedem, der an der Softwareentwicklung beteiligt ist. Entscheidend ist hier die direkte Rückkopplung zwischen allen Beteiligten. Das unterscheidet CoMo-Ansätze z. B. von einer klassischen Requirements-Technik, bei der Interviews geführt und daraus Szenarien abgeleitet werden.

CoMo hat einen hohen Stellenwert im Domain-driven Design, der wohl aktuell erfolgreichsten Methode, die die Fachlichkeit ins Zentrum der Softwareentwicklung stellt. Fachsprache, Ereignisse, Handlungen, Arbeitsmittel und Strukturen der Domäne bilden das sogenannte Domänenmodell, das die Entwickler in der Software abbilden. Ein valides Domänenmodell lässt sich nur gemeinsam von Entwicklern und Fachexperten erstellen. DDD-Experten wie Paul Rayner sehen CoMo mittlerweile als eine Säule des DDD an (Abb. 1). In diesem Artikel charakterisieren wir CoMo und stellen einige wichtige darin enthaltene Ansätze vor, mit denen sich die verschiedenen Aspekte eines Domänenmodells gemeinschaftlich erarbeiten lassen.

hofer_schwentner_zuellighoven_como_1.tif_fmt1.jpgAbb. 1: Collaborative Modeling als Säule des DDD [1]

Grundlegende Konzepte des CoMo

Die verschiedenen Techniken des CoMo verbindet folgende gemeinsame Konzepte:

  • Gruppenarbeit aller Beteiligten: Grundlegend ist, dass die verschiedenen Beteiligten auf Anwender- und Entwicklerseite gemeinsam Arbeitsprozesse und Anforderungen klären und nicht einzelne Spezialisten auf der Basis von Interviews und Dokumentanalysen diese Themen spezifizieren. Alle Ansätze sehen gemeinsame Workshops vor, manchmal in großen Gruppen, manchmal mit wenigen Vertreter der jeweiligen Gruppen.

  • Geschichten erzählen: In den Workshops kommunizieren die Beteiligten nicht über abstrakte Beschreibungen, sondern mittels konkreter Szenarien. Diese werden wie Geschichten erzählt. Aus dem fundierten Verständnis der Szenarien werden dann die für die Softwareentwicklung nötigen Abstraktionen und eine vollständige Abbildung von Regeln und Fallunterscheidungen aufgebaut.

  • Über eine gemeinsame Sprache ein wechselseitiges Verständnis aller Beteiligter anstreben: Oft wird beklagt, dass die Fachabteilungen und die IT in ihren eigenen Welten leben und aneinander vorbeireden. Alle CoMo-Ansätze stellen daher die Sprache der Anwender in den Vordergrund; die verschiedenen Workshoptechniken sollen helfen, dass sich die Beteiligten besser verstehen.

  • Gemeinsame Modelle des Anwendungsbereichs erstellen: Unsere Erfahrungen mit CoMo zeigen, dass die gemeinsame Arbeit ein gegenständliches Ergebnis haben sollte. Die verschiedenen Modelle aus Zeichnungen, Karteikarten oder Post-its sind mehr als ein Nebenprodukt. Sie zeigen allen Beteiligten den Stand der Diskussion, geben durch ihre grafische Darstellung eine neue Sicht auf das Thema und markieren am Ende eines Workshops ein handfestes Ergebnis, das oft in der weiteren Arbeit genutzt werden kann.

CoMo-Ansätze

Sehen wir uns nun kurz einige ausgewählte Ansätze des CoMo an, die aktuell in der Praxis erfolgreich eingesetzt werden. Diese Auswahl ist nicht vollständig und orientiert sich an unserer persönlichen Erfahrung. Außerdem sind die Ansätze so gut im Internet beschrieben, dass Sie sich dort als Leser leicht ein eigenes Bild machen können.

Event Storming

Beim Event Storming [2] erarbeiten sich Entwickler und Fachleute aus verschiedenen Bereichen mit Hilfe von Klebezetteln (Stickies) und Stiften ein Bild komplexer Geschäftsprozesse. Das Bild entsteht bottom-up aus einer Folge von fachlichen Ereignissen (sogenannte Domain Events), die eine konkrete Ausprägung des zu modellierenden Geschäftsprozesses beschreiben. Die Stickies erzählen also eine Geschichte. So werden Inkonsistenzen und Reibungspunkte zuverlässig entdeckt. Das Bild ist die Repräsentation des kollektiven Verständnisses der Domäne und ein guter Ausgangspunkt für Design und Implementierung nach DDD.

Namensgebend für Event Storming ist, dass im Workshop zunächst alle Teilnehmer (wie im Brain Storming) unkoordiniert herausstürmen, was in der Domäne passiert. Dazu schreiben sie, ohne sich abzusprechen, Domain Events auf orangefarbene Stickies und kleben sie auf eine Wand (Abb. 2). Je nach Ziel des Workshops werden schrittweise weitere Farben eingeführt, z. B. pink für Hot Spots (Probleme, Konflikte, Fragen) und lila für Policies (Geschäftsregeln).

hofer_schwentner_zuellighoven_como_2.tif_fmt1.jpgAbb. 2: Big Picture Event Storming mit Events und Hot Spots

Domain Storytelling

Domain Storytelling hat sich über Jahre als graphische Modellierungsmethode von Aufgaben und Geschäftsprozessen entwickelt [3]. Die Methode nutzt eine einfache Bildsprache, um Geschichten über den Anwendungsbereich zu erzählen und zu dokumentieren (Abb. 3). In gemeinsamen Workshops von Vertretern der Fachabteilung und des Entwicklungsteams unter Leitung eines Moderators werden Geschichten über ausgewählte Geschäftsprozesse erzählt und in Bildern festgehalten. Normalerweise reichen wenige Domain Stories aus, um einen Geschäftsprozess zu verstehen.

Domain Storytelling funktioniert auch für das Design von neuen, softwaregestützten Prozessen. Veränderungen zwischen Ist- und Sollprozessen lassen sich damit anschaulich darstellen.

hofer_schwentner_zuellighoven_como_3.tif_fmt1.jpgAbb. 3: Aus der Domäne „Flughafen“: Passagiere vom Gate zum Rollfeld fahren

User Story Mapping

User Story Mapping [4] kommt aus der agilen Community. Eine User Story Map strukturiert Anforderungen (grob festgehalten als User Stories) in einer zusammenhängenden Geschichte aus Sicht der Benutzer der zu entwickelnden Anwendung. Kurze Sätze aus der Interaktion mit der Software werden aus Benutzersicht mit Stickies in eine zeitliche Abfolge gebracht (die horizontale Dimension der Map). In der vertikalen Dimension werden User Stories auf die Zeitachse „gemappt“ (Abb. 4).

Story Mapping wird häufig in drei Phasen unterteilt, in denen verschiedene Aspekte mit unterschiedlichen Personen erarbeitet werden: Produktfindung, Versionsstrategie und Backlog Grooming.

hofer_schwentner_zuellighoven_como_4.tif_fmt1.jpgAbb. 4: Aus der Domain Story aus Abb. 3 abgeleitete User Story Map

Example Mapping

Auch beim Example Mapping [5] sind User Stories der Ausgangspunkt, um den Problembereich genauer zu verstehen. Anhand von Beispielen sollen vor allem Vertreter der Fachabteilung, Entwickler und Tester die fachlichen Regeln oder Randbedingungen einer User Story identifizieren, um daraus Akzeptanztests abzuleiten. User Stories, Regeln mit Beispielen und offene Fragen werden jeweils auf verschiedenfarbigen Karten notiert (Abb. 5).

Example Mapping wird oft zu Beginn eines Sprints genutzt, um User Stories auf eine implementierbare Größe zu reduzieren und offene Fragen zu identifizieren.

hofer_schwentner_zuellighoven_como_5.tif_fmt1.jpgAbb. 5: User Story mit Beispielen (links) und durch die Beispiele gefundene neue User Stories (rechts)

Unterschiede der CoMo-Ansätze

Die gemeinsamen Konzepte der verschiedenen Ansätze haben wir schon herausgearbeitet. Für den praktischen Einstieg in das Collaborative Modeling geben wir jetzt eine kleine „Gebrauchsanweisung“ für die Auswahl der passenden Methode. Dafür gehen wir auf die Unterschiede der Ansätze ein. In Tabelle 1 betrachten wir folgende Aspekte:

  • Zielsetzung, d. h. wozu ist der Ansatz gut?

  • Welcher Gegenstandsbereich wird betrachtet?

  • Welche Elemente werden bei der Modellierung verwendet?

  • Welche Ergebnisse (Modelle, Gegenstände, Artefakte) werden bei der CoMo erzeugt?

  • Welche Aktivitäten im Entwicklungsprozess werden durch den Ansatz unterstützt?

  • Welche Verbindungen zu anderen Entwicklungsmethoden und Modellierungsansätzen bestehen?

Eine solch kompakte Übersicht ist zwangsläufig vereinfachend und nicht ganz trennscharf. Außerdem decken die Ansätze eine Bandreite von Einsatzzwecken ab und können mit etwas Erfahrung flexibel an die eigenen Gegebenheiten angepasst werden.

Event Storming

Domain Storytelling

User Story Mapping

Example Mapping

Warum wird modelliert?

gemeinsam Überblick gewinnen

Ziele, Konflikte und offene Fragen identifizieren

fachliche Grenzen in Prozessen erkennen

Softwaredesign

Geschäftsprozesse verstehen und entwerfen

Anforderungen an Software ableiten

fachliche Grenzen in Prozessen erkennen

Anforderungen an Software verstehen und detaillieren

sinnvolle Inkremente definieren

Strukturieren von Backlogs

Anforderungen an Software zerlegen

Anforderungen durch Akzeptanzkriterien implementierbar machen

Was wird betrachtet?

Geschäftsprozesse im Ist oder Soll

zeitliche Abfolge von Ereignissen im Allgemeinen

Geschäftsprozesse im Ist oder Soll

Kooperation zwischen Akteuren

Umgang mit Softwaresystemen

Aufgaben

Aktivitäten

Ziele

User Stories

Fachliche Anforderungen

Wichtige Elemente der Modellierung

Events (fachliche Ereignisse)

dazu ggf. Regeln, Systeme, Akteure, softwaretechnische Bausteine, …

menschliche und technische Akteure

Arbeitsgegenstände

Aktivitäten

Ziele

Aufgaben

Aktivitäten

User Stories

User Stories

Regeln

Beispiele für Regeln

offene Fragen

Wichtige Artefakte

Bild eines Geschäftsprozesses als Folge von Events

Bild eines Domänenmodells

Domain Story als Bild

Glossar einer Ubiquitous Language

User Stories

User Story Map mit User Journeys und Inkrementen

Example Map einer Anforderung mit Regeln, Beispielen und offenen Fragen

User Stories mit Akzeptanzkriterien

Welche Entwicklungs-aktivitäten werden unterstützt?

Softwaredesign nach DDD

Übergang vom Problemverständnis zur Implementierung

Identifikation fachlicher Schnittstellen zu externen Systemen

Anforderungsermittlung

Priorisierung der IT-Unterstützung von Aufgaben und Prozessen

Entwurf von Mock-ups

Softwareentwicklung mit Interaktionsmodellen

Planung von Inkrementen

Priorisierung Backlog

Weiterentwicklung und Wartung

Softwareentwicklung, bes. Implementierung

Spezifikation von Constraints und Regeln

Spezifizierung von Akzeptanztests

Verbindungen zu anderen Methoden

Domain Stories für Detailanalysen kooperativer Teile

Context Mapping für gefundene Bounded Contexts

Geschäftsregeln in Example Mapping ausarbeiten

Event Storming für Software Design nach DDD

Context Mapping für gefundene Bounded Contexts

Use-Case-Diagramme als Überblick

Design Studio und Mock-ups für das Interaktionsmodell

Example Mapping für abgeleitete User Stories

Design Studio und Mock-ups für das Interaktionsmodell

Planung nach XP oder Scrum

Abarbeitung durch Kanban Boards steuern

Vorbereitung von Sprints

Arbeit mit Backlog

testgetriebene Entwicklung

Die Verbindungen zu anderen Methoden haben wir in Abbildung 6 grafisch als eine Art Wegweiser durch die CoMo-Landschaft aufbereitet.

Abschließend geben wir noch einige persönliche Erfahrungen weiter, anhand derer wir abwägen, welche Methode wir wann einsetzen.

hofer_schwentner_zuellighoven_como_6.tif_fmt1.jpgAbb. 6: Methoden, Artefakte und Umwelt des CoMo

Event Storming

Event Storming spielt seine Stärken in der fachlichen Prozessmodellierung dann aus, wenn

  • der Anwendungsbereich schwach strukturiert ist,

  • wenn die Domäne von zeitlichen Abläufen und Statuswechseln geprägt ist

  • oder schon vorab klar ist, dass es wenig gemeinsame Sichtweisen und Ziele, aber viel Konfliktpotenzial gibt.

Die Ergebnisse der Prozessmodellierung können durch zusätzliche Notationselemente in kleineren Workshops zu einem Softwaredesign ausgearbeitet werden. Eine solche Modellierung passt gut, wenn Software nach DDD gebaut werden soll.

Domain Storytelling

Domain Storytelling nutzen wir gerne, wenn

  • wir kooperative Prozesse betrachten und dadurch verstehen wollen, wie menschliche (und technische) Akteure zusammenarbeiten,

  • wir softwaregestützte Sollprozesse entwerfen und dann über den Weg vom Ist zum Soll diskutieren,

  • wir funktionale Anforderungen an die Prozessunterstützung ableiten wollen

  • oder Prozesse dokumentiert werden müssen.

User Story Mapping

User Story Mapping setzen wir dann ein, wenn die Sollprozesse bereits eine gewisse Reife haben und die daraus abgeleiteten Anforderungen in ein Backlog überführt werden. Die User Story Map wird zum Planungsinstrument für cross-functional Scrum-Teams, um

  • mit einem Product Owner über Prioritäten und Inkremente zu sprechen,

  • den fachlichen Kontext einer User Story nicht aus den Augen zu verlieren

  • und um zu veranschaulichen, welche Anforderungen als nächstens detailliert ausgearbeitet werden müssen.

Example Mapping

Mit Example Mapping arbeiten wir weiter an den Zwischenergebnissen der anderen Methoden, um

  • die im Event Storming oder Domain Storytelling identifizierten Stellschrauben für Prozessvarianten (meist sind das Geschäftsregeln) zu analysieren,

  • Anforderungen auf ein implementierbares Niveau zu detaillieren

  • oder wenn bei der Planung klar wird, dass Anforderungen kleiner geschnitten werden müssen.

Wo finde ich mehr zu Collaborative Modeling?

Die internationale CoMo-Community, meist Vertreter der DDD- und BDD-Szenen, schreibt gerade ein Buch über Collaborative Modeling. Darin werden viele Methoden vorgestellt, ihre Einsatzzwecke erläutert und gezeigt, wie man Methoden miteinander kombinieren kann [6]. Ein ähnliches Projekt ist die Open Practice Library [7]. Sie enthält nützliche Methoden für die Softwareentwicklung und einige CoMo-Methoden.

Wenn wir Sie für DDD interessieren konnten, empfehlen wir Ihnen als ersten Einstieg das Buch „Domain-Driven Design kompakt“ [8].

Danksagung: Wir bedanken uns bei Martin Schimak für das Foto von Paul Rayners „Säulen des DDD“.

hofer_stefan_dr_sw.tif_fmt1.jpgDr. Stefan Hofer beschäftigt sich bei der WPS – Workplace Solutions GmbH mit Requirements Engineering, Domain-driven Design und Geschäftsprozessen. Als einer der Köpfe hinter Domain Storytelling rückt er die Sprache der Fachexperten in den Mittelpunkt der Anforderungsermittlung.

Mail

schwentner_henning_sw.tif_fmt1.jpgHenning Schwentner lebt seine Leidenschaft für guten Code als Entwickler, Coach und Consultant bei der WPS – Workplace Solutions GmbH aus. Dort hilft er Teams dabei, ihre gewachsenen Monolithen zu strukturieren oder neue Systeme von Anfang an mit einer tragfähigen Architektur zu errichten. Henning ist Autor von www.LeasingNinja.io sowie Übersetzer von „Domain-Driven Design kompakt“.

Mail

zuellighoven_heinz_dr_sw.tif_fmt1.jpgProf. Dr.-Ing. Heinz Züllighoven ist geschäftsführender Gesellschafter der WPS – Workplace Solutions GmbH und leitete bis 2015 den Lehrstuhl für Softwarearchitektur an der Universität Hamburg.

Mail
Henning Schwentner

Henning liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Coder, Coach und Consultant bei der WPS – Workplace Solutions aus. Dort hilft er Teams dabei, Ihre gewachsenen Monolithen zu strukturieren oder neue Systeme von Anfang an mit einer tragfähigen Architektur zu errichten. Häufig kommen dann Microservices oder Self-Contained Systems heraus. Henning ist Autor von mehreren Domain-driven Design Büchern.

Dr. Stefan Hofer

Dr. Stefan Hofer kann nicht gut zeichnen. Trotzdem glaubt er fest daran, dass man durch Zeichnen von Domain Stories Domänenwissen aufbauen kann. Er studierte Software Engineering an der FH Oberösterreich und promovierte an der Universität Hamburg über die Umgestaltung von Anwendungslandschaften. Er arbeitet seit 2005 bei der WPS – Workplace Solutions GmbH. Requirements Engineering und Anwendungslandschaften bilden seine Themenschwerpunkte. Als einer der Köpfe hinter „Domain Storytelling“ rückt er die Sprache der Fachexperten in den Mittelpunkt der Anforderungsermittlung.

Prof. Dr.-Ing. Heinz Züllighoven

Prof. Dr.-Ing. Heinz Züllighoven ist geschäftsführender Gesellschafter der WPS – Workplace Solutions GmbH und leitete bis 2015 den Lehrstuhl für Softwarearchitektur an der Universität Hamburg.