Wie Entwickler und Fachexperten gemeinsam Domain-driven-Software entwickeln
Wie Entwickler und Fachexperten gemeinsam Domain-driven-Software entwickeln
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.
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.
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.
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.
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).
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.
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.
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.
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.
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 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 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.
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.
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“.
Dr. 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.
Henning 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“.
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.
[1] Rayner, Paul: Workshop auf der Explore DDD 2018
[2] Brandolini, Alberto: „Introducing EventStorming“: https://leanpub.com/introducing_eventstorming
[3] Hofer, Stefan; Schwentner, Henning: „Domain Storytelling“: https://leanpub.com/domainstorytelling/
[4] Patton, Jeff: „User Story Mapping“; O’Reilly, 2014
[5] Wynne, Matt: „Introducing Example Mapping“: https://cucumber.io/blog/bdd/example-mapping-introduction/
[6] https://visualcollaborationtools.com
[7] https://openpracticelibrary.com
[8] Vernon, Vaughn: „Domain-Driven Design kompakt“; dpunkt, 2017