Domain-Driven Transformation E-Book

Carola Lilienthal

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2023

Seitenzahl: 350

Beschreibung

Über den Umbau von IT-Landschaften mit Domain-Driven Design - kompakter, tiefgehender Einblick in Domain-Driven Design (DDD) und die Verwendung der vielfältigen DDD-Techniken in der Praxis – Fokussierung auf Legacy-Systeme und Migration in Richtung gut strukturierter Monolithen und Microservices - Zusammenhang zwischen Transformation der Architektur und der TeamorganisationIn den letzten Jahrzehnten ist sehr viel Software entwickelt worden, die wir heute modernisieren und zukunftsfähig machen wollen. Domain-Driven Design (DDD) eignet sich hervorragend, um große Legacy-Systeme in Microservices zu zerlegen oder zu wartbaren Monolithen umzubauen. In diesem Transformationsprozess wird der fachliche Kern des Softwaresystems herausgearbeitet. Auf der Makro-Architektur-Ebene wird das System in unabhängige DDD-Module aufgeteilt. Auf der Mikro-Architektur-Ebene werden zusätzlich DDD-Muster eingesetzt, um den Code weiter zu strukturieren.   Dieses Buch kombiniert Anleitungen, Erkenntnisse und Beispiele aus der Beraterpraxis des Autorenteams. Es veranschaulicht, wie Techniken aus DDD und Refactorings verwendet werden können, um Softwaresysteme zu transformieren, die über Jahre gewachsen und möglicherweise ohne Architekturverständnis entwickelt wurden. Die Leser*innen lernen einen Prozess der Transformation kennen, den sie als Ganzes oder schrittweise in ihre Alltagspraxis übernehmen können, um die Wartbarkeit ihrer Legacy-Systeme effektiv und schnell zu verbessern. Sie erhalten: - einen detaillierten Einblick in DDD und die Verwendung der vielfältigen DDD-Techniken in der Praxis, - eine Anleitung, wie DDD eingesetzt werden kann, damit Legacy-Systeme wartbar bleiben oder wartbarer werden, - eine Anleitung, wie vorzugehen ist, falls eine Zerlegung der Monolithen und eine Neustrukturierung der Microservices geplant ist, - Argumente an die Hand, wann eine Zerlegung in Microservices für einen Monolithen sinnvoll ist und wann nicht. 

Leseprobe

Dr. Carola Lilienthal ist Geschäftsführerin der WPS – Workplace Solutions GmbH in Hamburg und verantwortet dort den Bereich Softwarearchitektur. Sie hat 1995 an der Universität Hamburg ihr Diplom in Informatik gemacht und dort zum Thema »Komplexität von Softwarearchitekturen« promoviert. Seit 2003 analysiert sie international im Auftrag ihrer Kund*innen die Architektur von Softwaresystemen und berät Entwicklungsteams, wie sie die Langlebigkeit ihrer Softwaresysteme verbessern können. Insgesamt hat sie mit ihrem Team über dreihundert Softwaresysteme zwischen 30.000 und 15 Mio. LOC in Java, C++, C#, ABAP, PHP und TypeScript untersucht. Besonders am Herzen liegt ihr die Ausbildung von Softwarearchitekt*innen und Entwickler*innen, weshalb sie aktives Mitglied im iSAQB, International Software Architecture Qualification Board, ist und ihr Wissen aus über 25 Jahren Softwareentwicklung regelmäßig auf Konferenzen, in Artikeln und bei Schulungen weitergibt.

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 Storytelling und LeasingNinja.io, hat zusammen mit Carola Lilienthal Domain-Driven Design kompakt übersetzt und ist Mitorganisator des Como-Camps. Er schreibt im Fediverse als @[email protected] und twittert als @hschwentner. 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.

Carola Lilienthal · Henning Schwentner

Domain-DrivenTransformation

Monolithen und Microservices zukunftsfähig machen

Carola Lilienthal · [email protected]

Henning Schwentner · [email protected]

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:

Print

978-3-86490-884-2

PDF

978-3-96910-764-5

ePub

978-3-96910-765-2

mobi

978-3-96910-766-9

1. Auflage 2023

Copyright © 2023 dpunkt.verlag GmbH

Wieblinger Weg 17 · 69123 Heidelberg

Hinweis:

Dieses Buch wurde mit mineralölfreien Farben auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie. Hergestellt in Deutschland.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

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

Vorwort

»Alle glücklichen Familien gleichen einander, jede unglückliche Familie ist auf ihre eigene Weise unglücklich.« Dieses Anna-Karenina-Prinzip gilt nicht nur für Familien, sondern auch für Entwicklungsteams von Legacy-Software. Verschiedene Softwaresysteme leiden unter unterschiedlichen »Krankheiten« und wir brauchen eine Vielzahl von Mitteln, um sie alle zu heilen. Die folgenden Krankheiten haben wir in unterschiedlichen Kombinationen in den letzten Jahren bei Legacy-Systemen – egal ob Monolithen oder Microservices – und ihren Organisationen beobachten können:

Das Legacy-System ist ein

Big Ball of Mud

geworden, weil niemand die Abhängigkeiten kontrolliert hat und nun alles mit allem verbunden ist (s.

Kap. 4

).

Die Fachlichkeit ist in einem

großen Domänenmodell

miteinander verwoben, dessen Teile nur begrenzt zusammenpassen oder sich sogar widersprechen (s.

Abschnitt 11.4

).

Der

fachliche und technische Sourcecode

ist vermengt, und so wird der Austausch von veralteter Technik oder eine fachliche Erweiterung zu einer Herkulesaufgabe (s.

Kap. 7

).

Die Menschen sind in einer

Teamstruktur

organisiert, die für schnelles Vorankommen ungeeignet ist (s.

Kap. 8

).

In diesem Buch stellen wir die Heilmittel gegen diese Krankheiten vor, die wir in den letzten 20 Jahren bei unserer Arbeit mit Domain-Driven Design (DDD) und Legacy-Software kennenlernen durften. Dazu gehören: Refactorings, Domain Storytelling, Event Storming, Team Topologies und der Modularity Maturity Index (MMI). Wenn wir in unseren Projekten und mit unseren Kunden die Heilung angehen, dann erreichen wir, dass das jeweilige Entwicklungsteam deutlich positiver in die Zukunft schaut und die Motivation steigt. Je weiter die Heilung voranschreitet, desto glücklicher werden auch unsere Fachanwender, Projektleiter und Manager sein, denn die schwergängige und teure Legacy-Software wird stabiler, lässt sich schneller anpassen und erlaubt schließlich sogar (wieder) innovative, zukunftsweisende Erweiterungen.

Unser Ziel mit diesem Buch ist es, Ihnen Mittel an die Hand zu geben, die Ihnen helfen, Ihre Softwaresysteme so aufzuteilen, dass Änderungen möglichst lokale Auswirkungen haben. Dadurch werden die einzelnen Softwaremodule für die Entwicklungsteams wieder beherrschbar und verstehbar und können von entsprechend kleinen schlagkräftigen Teams bearbeitet werden. Deshalb finden Sie in diesem Buch eine ganze Reihe Sourcecode-Beispiele. Die Legacy-Systeme, die uns begegnen, sind in ganz unterschiedlichen Programmiersprachen1 gebaut: Java, C#, PHP, C++ und viele andere. Wir haben uns entschieden, die Beispiele in der Sprache zu schreiben, die im Vergleich am häufigsten auftaucht, nämlich Java. Die Beispiele sind kurz genug, dass sie auch Programmierern anderer Sprachen verständlich sein sollten, und das Vorgehen, das wir beschreiben, ist unabhängig von der Programmiersprache.

Einige Leserinnen und Leser haben möglicherweise unsere anderen Bücher Langlebige Softwarearchitekturen[Lilienthal 2019] und Domain Storytelling[Hofer & Schwentner 2023] gelesen. Das vor Ihnen liegende Buch ist für uns die Vereinigung und logische Folge aus den beiden anderen Büchern und unserer täglichen Arbeit in unseren Projekten. Die Leser dieser beiden Bücher werden die Beispieldomänen Kino und Autoleasing und unsere Sicht auf Architektur wiedererkennen. Darüber hinaus gibt es viel Neues zu entdecken :-) Wir hoffen sehr, dass Ihnen diese Synthese gefällt, und freuen uns auf Ihr Feedback!

Ganz besonders möchten wir uns an dieser Stelle bei allen bedanken, die uns in den letzten Jahren unterstützt, uns Ideen für dieses Buch gegeben und mit uns diskutiert haben. Die sehr aktive und engagierte DDD-Community und unsere Firma, die WPS – Workplace Solutions, seien hier als Erstes genannt. Ohne ein gutes Umfeld wäre es uns nicht möglich, die Energie aufzubringen, die es für das Schreiben eines Buches braucht. Viele der hier präsentierten Ideen haben ihren Ursprung bei Christiane Floyd und Heinz Züllighoven. Danke, dass wir von euch lernen durften!

Unsere beiden Kollegen Stefan Hofer und Sönke Magnussen haben unsere Texte gereviewt und uns mit ihren kritischen, konstruktiven Anmerkungen zu einem deutlich besseren Ergebnis verholfen. Unsere Lektorin Christa Preisendanz vom dpunkt.verlag hat uns wieder einmal hervorragend betreut und motiviert. Danke, Christa!

Unsere Familien haben unsere Fokussierung auf ein weiteres Buch voller Verständnis begleitet und uns Freiraum und Unterstützung gegeben. Henning dankt seiner Frau Julia und seinen Kindern Lennart, Joris, Friedo, Tara, Aurelia und Viola für ihre großartige Unterstützung. Carola dankt ihrem Mann, ihrem Sohn und ihren Freunden für einfach alles. Herzlichen Dank an euch alle!

Was die geschlechtergerechte Sprache angeht, haben wir uns für dieses Buch entschieden, abwechselnd pro Kapitel die weibliche und männliche Form zu verwenden. Dann bleibt das Lesen flüssig und jede und jeder kann sich hoffentlich inkludiert fühlen.

Carola Lilienthal und Henning Schwentner

Hamburg, April 2023

www.domain-driven-transformation.com

Inhaltsübersicht

1Einleitung: Komplexität beherrschen

Teil IGrundlagen für Domain-Driven Transformation

2Domain-Driven Design

3Collaborative Modeling

4Architekturkonzepte

5Vorgehen klären

Teil IITechnische, taktische und teamorganisatorische Domain-Driven Transformation

6Legacy-Software technisch stabilisieren

7Fachlichkeit stärken

8Teamorganisation verbessern

Teil IIIStrategische Domain-Driven Transformation

9Schritt 1 – Wiederentdecken der Fachdomäne

10Schritt 2 – Modellierung der fachlichen Soll-Architektur

11Schritt 3 – Abgleich Ist- mit Soll-Architektur

12Schritt 4 – Priorisierung und Durchführung der Umbaumaßnahmen

Abschluss

13Ausblick: Domain Patterns und ihre Umsetzung in Kontexten

14Fazit

Anhang

Literatur

Index

Inhalt

1Einleitung: Komplexität beherrschen

1.1Komplexität

1.2Herkunft der Komplexität: Problem- und Lösungsraum

1.3Art der Komplexität: essenziell vs. akzidentell

1.3.1Quellen akzidenteller Komplexität

1.3.2Entscheidungsbereiche von Softwarearchitektur

1.4Komplexität in Legacy-Systemen

1.5Struktur dieses Buches

Teil IGrundlagen für Domain-Driven Transformation

2Domain-Driven Design

2.1DDD-Konzepte gegen Komplexität

2.2DDD und die Fachdomäne

2.2.1Ubiquitous Language

2.2.1.1Begriffsmodelle

2.2.1.2Glossare

2.2.1.3Verschmutzung der Fachsprache mit technischen Begriffen

2.2.1.4Deutsch oder Englisch?

2.2.2Strategisches Design in der Domäne

2.2.3Subdomänen kategorisieren – was ist der Kern?

2.2.3.1Core Domain

2.2.3.2Generic und Supporting Subdomain

2.3DDD und die Softwarelösung

2.3.1Strategisches Design in der Technik

2.3.1.1Bounded Context

2.3.1.2Context Map

2.3.2Context Mapping

2.3.2.1Dimension »Zusammenarbeit zwischen den Teams«

2.3.2.2Dimension »Technische Umsetzung der Schnittstelle«

2.3.3Bubble Context

2.3.4Das Domänenmodell

2.3.4.1Domänenmodell im Kontext

2.3.4.2Wiederverwendung, Duplikation und Redundanz

2.3.5Die Schichtenarchitektur in DDD

2.3.6Taktisches Design

2.3.7Domain Events

2.4Zusammenfassung

3Collaborative Modeling

3.1Die richtigen Leute zusammenbringen

3.2Grundlegende Konzepte des Collaborative Modeling

3.3Modellierungswerkzeuge und das Modellmonopol

3.4Collaborative Modeling und DDD

3.5Domain Storytelling

3.5.1Ein Bild – eine Geschichte

3.5.2Grenzen ziehen

3.5.3Scope-Faktoren für Domain Stories

3.5.4Das Domänenmodell finden

3.5.5Ausblick

3.6Event Storming

3.6.1Storming-Phase

3.6.2Zeitliche Ordnung herstellen

3.6.3Grenzen ziehen

3.6.4Die Farbcodierung

3.6.5Tiefer ins Detail: Design Level Event Storming

3.6.6Das Domänenmodell finden

3.6.7Weitere Formate und Ausblick

3.7Wann welche Methode einsetzen?

3.8Collaborative Modeling Remote

3.9Andere Techniken des Collaborative Modeling

3.10Zusammenfassung

4Architekturkonzepte

4.1Modularität

4.2Kohäsion und Kopplung

4.2.1Kohäsion und Kopplung in der Fachlichkeit

4.3Big Ball of Mud

4.3.1Auf Klassenebene

4.3.2Auf Architekturebene

4.3.3Entstehen eines Big Ball of Mud

4.3.4Kopplung und Wiederverwendung

4.4Monolith

4.5Microservices

4.6Vom Monolithen zu Microservices

4.7Die gute alte Schichtenarchitektur

4.8Hexagonal Architecture und ihre Varianten: Onion, Clean und mehr

4.8.1Verschiedene Stile zusammen – Explicit Architecture

4.8.2Innen-außen-Architekturen und taktisches DDD

4.9Software Architecture Hamburger

4.10Serviceorientierte Architekturen (SOA)

4.11Self-Contained Systems

4.12Von IT-Landschaften zu SOA und wieder zurück

4.13Der Modularity Maturity Index: Wo stehen Sie?

4.13.1Modularität im MMI

4.13.2Hierarchie im MMI

4.13.3Musterkonsistenz im MMI

4.13.4Beispielhafter MMI verschiedener Systeme

4.14Zusammenfassung

5Vorgehen klären

5.1Der MMI und die Wege durch die Domain-Driven Transformation

5.1.1Big Ball of Mud (MMI 0–4 – rot)

5.1.2Technische Schichtenarchitektur (MMI 4–8 – gelb)

5.1.3Fachliche Modularisierung (MMI 8–10 – grün)

5.2Auswahl des Vorgehens

5.2.1Ersetzen – Big Bang Replacement

5.2.2Ersetzen – schrittweise Ablösung

5.2.3Umformen

5.3Zusammenfassung

Teil IITechnische, taktische und teamorganisatorische Domain-Driven Transformation

6Legacy-Software technisch stabilisieren

6.1Build und Deployment automatisieren

6.2Verwendete Software aktualisieren

6.2.1Abhängigkeiten aktualisieren

6.2.2Die Programmiersprache aktualisieren

6.3Testabdeckung beim Bugfixing erhöhen

6.3.1Die Pfadfinderregel

6.3.2Unterschiedliche Arten von Tests

6.4Refactoring

6.4.1Abhängigkeit aufbrechen

6.4.2Compiler- und IDE-Warnungen auflösen

6.4.3Interne Struktur anhand von Metriken verbessern

6.5Fehlerrobustheit

6.5.1Robustheit gegenüber null aufbauen

6.5.2Einsatz von Exceptions glattziehen

6.5.3Design by Contract einführen

6.6Zusammenfassung

6.7Wo stehen Sie?

7Fachlichkeit stärken

7.1Fachlichen und technischen Sourcecode trennen

7.2Kohäsion erhöhen

7.2.1Modellierung fachlich anreichern

7.2.2Value Objects einsetzen

7.2.3Design by Contract einführen

7.2.4Identität von Entities explizit machen

7.3Kopplung verringern

7.3.1Zyklen und Abhängigkeiten auflösen

7.3.2An Aggregate-Grenzen ID-Referenzen einführen

7.3.3Vererbung im fachlichen Sourcecode reduzieren

7.3.4Das Liskov Substitution Principle (LSP)

7.4Architektur im Code dokumentieren

7.5Zusammenfassung

7.6Wo stehen Sie?

8Teamorganisation verbessern

8.1Software als soziotechnisches System

8.1.1Architekturschnitt/Teamorganisation horizontal

8.1.1.1Spezialfall Framework-Team

8.1.1.2Probleme mit dem horizontalen Schnitt

8.1.2Architekturschnitt/Teamorganisation vertikal

8.1.3Wie führt man diese Teamreorganisation durch?

8.2Team Topologies

8.2.1Arbeiten im Flow

8.2.2Arten von Topologien

8.2.3Arten von Zusammenarbeit

8.2.4Teamentwicklung in der Zeit

8.2.5Architecture Modernization Enabling Teams

8.3Zusammenfassung

8.4Wo stehen Sie?

Teil IIIStrategische Domain-Driven Transformation

9Schritt 1 – Wiederentdecken der Fachdomäne

9.1Schematische Beschreibung von Schritt 1

9.2Herausforderung: Fachexperten bekommen

9.3Herausforderung: Fachexperten auf die eigentliche Fachlichkeit zurückführen

9.4Teilschritt 1.1: Kennenlernen der Ist-Situation

9.5Teilschritt 1.2: Herausschälen der Fachlichkeit (Purifizieren)

9.5.1Technik: Gedankenexperiment »Papierprozess«

9.5.2Technik: Gedankenexperiment »Virtuelle Akteure«

9.5.3Alternative: gleich pur modellieren

9.5.4Ubiquitous Language destillieren

9.6Teilschritt 1.3: Optimieren der Prozesse hin zu Soll-Prozessen

9.7Teilschritt 1.4: Subdomänen im Arbeitsprozess finden

9.7.1Indikatoren für Subdomänengrenzen

9.8Herausforderung: Aufteilung der Subdomänen nicht nach Arbeitsgegenständen

9.9Herausforderung: richtige Größe finden

9.9.1Ziele der richtigen Größe

9.9.2Indikatoren für die richtige Größe

9.10Zusammenfassung

10Schritt 2 – Modellierung der fachlichen Soll-Architektur

10.1Schematische Beschreibung von Schritt 2

10.2Teilschritt 2.1: Context Map erstellen

10.3Herausforderung: Lösungsraum-induzierte Kontexte

10.4Teilschritt 2.2: Subdomänen kategorisieren

10.5Teilschritt 2.3: Kontexte an Teams zuteilen

10.6Herausforderung: Teams zuordnen, heißt oft Teams formen

10.7Teilschritt 2.4: Beziehungen bestimmen

10.8Alles zusammen

10.9Zusammenfassung

11Schritt 3 – Abgleich Ist- mit Soll-Architektur

11.1Schematische Beschreibung von Schritt 3

11.2Teilschritt 3.1: Ist-Architektur ermitteln

11.3Teilschritt 3.2: Soll-Context-Map auf den Sourcecode legen

11.4Herausforderung: übergreifende Modelle

11.4.1Zerlegung von innen nach außen

11.5Herausforderung: das übergreifende Domänenmodell

11.5.1Problemursache: Wiederverwendbarkeit missverstanden

11.6Herausforderung: das übergreifende anämische Domänenmodell

11.7Herausforderung: das übergreifende Datenmodell

11.8Herausforderung: Zerlegen der Benutzungsoberfläche

11.8.1Monolithische UI

11.8.2UI im Kontext: Micro Frontends

11.9Teilschritt 3.3: Refactorings und Findings zusammenstellen

11.10Zusammenfassung

12Schritt 4 – Priorisierung und Durchführung der Umbaumaßnahmen

12.1Schematische Beschreibung von Schritt 4

12.2Teilschritt 4.1: strategisches Refactoring auswählen

12.2.1Muster: eine Supporting Domain zuerst

12.2.2Muster: eine Core Domain als zweiten oder dritten Kontext

12.3Teilschritt 4.2: taktische Refactorings ins Product Backlog eintragen

12.4Teilschritt 4.3: leistbare Refactorings ins Sprint Backlog übertragen

12.4.1Nur in Notfällen den Umbau ruhen lassen

12.4.2Refactorings schätzen

12.4.3Domain-Driven Transformation mit Kanban

12.5Teilschritt 4.4: Kontext herauslösen

12.6Herausforderung: Fachlogik in den Services entflechten

12.7Herausforderung: lokale Daten, Setter und Getter in einen Kontextverschieben

12.7.1Identität von Entities

12.8Herausforderung: Daten, Setter und Getter in mehrere Kontexte duplizieren

12.9Herausforderung: fachliche Domain Events zwischen Services einführen

12.10Herausforderung: Fachlichkeit aus dem Service ins anämische Domänenmodell verschieben

12.10.1Logik aus den Services in die anämischen Entities herunterdrücken

12.11Herausforderung: Findings im geeigneten Moment auswählen

12.12Herausforderung: den langen Atem behalten

12.13Zusammenfassung

Abschluss

13Ausblick: Domain Patterns und ihre Umsetzung in Kontexten

13.1Ebene 1: Arbeitsablauf in der Domäne

13.1.1Domain Pattern »Pipeline«

13.1.2Domain Pattern »Blackboard«

13.1.3Domain Pattern »Dialog«

13.1.4Entwicklung von Domain Patterns

13.2Ebene 2: Das Domänenmodell in der Software

13.2.1Zentrales Domänenobjekt vs. diverse Domänenobjekte

13.2.2Formularbasiertes Domänenmodell

13.3Ebene 3: Ausprägung der Domäne

13.3.1Alter und Reife der Domäne

13.3.2Gegenständliche Domäne vs. vollständig digitalisierte Domäne

13.3.3Entwicklungspotenzial der Kontexte

13.4Zusammenfassung

14Fazit

Anhang

Literatur

Index

1Einleitung: Komplexität beherrschen

Wenn man auf der grünen Wiese mit einem Softwareprojekt anfängt, macht alles Spaß und alles ist einfach. Die Entwickler reagieren blitzschnell auf neue Anforderungen. Die Anwender sind begeistert. Die Entwicklung geht in großen Schritten voran.

Über die Lebenszeit des Systems wird sich das ändern. Unweigerlich erhöht sich die Komplexität der Software. Diese ansteigende Komplexität führt zu höherer Fehleranfälligkeit, immer langsamerem Fortschritt und schlechterer Wartbarkeit. Und schließlich braucht es ein halbes Jahr, bis auch nur die kleinste Änderung in Produktion angekommen ist. Aus der blühenden grünen Wiese ist ein schlammiger, stinkender Acker geworden. »Altsystem«, »Legacy-Software«, »Big Ball of Mud«, »Monolith«, »Gummistiefelprojekt« sind die wenig schmeichelhaften Namen, mit denen diese Art von Systemen versehen werden.

»The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: divide and conquer.«

Bjarne Stroustrup

Aber es gibt Hoffnung! Auch diesen in die Jahre gekommenen Systemen kann Flexibilität, Fehlerrobustheit und Entwicklungsgeschwindigkeit zurückgegeben werden. Kernaufgabe ist dabei die Beherrschung (und Aufteilung) von Komplexität.

1.1Komplexität

Um einordnen zu können, wie mit Komplexität bei der Softwareentwicklung umgegangen werden kann, ist der Untertitel von Eric Evans’ Buch Domain-Driven Design ein guter Wegweiser: Tackling Complexity in the Heart of Software[Evans 2004]. Evans gibt uns das Versprechen, dass das von ihm beschriebene Vorgehen Komplexität in der Software(-entwicklung) reduziert oder zumindest handhabbar macht. Domain-Driven Design hilft dabei auf unterschiedlichen Ebenen. In Abbildung 1–1 sind die verschiedenen Aspekte von Komplexität, die uns bei der Softwareentwicklung begegnen, in Anlehnung an [Lilienthal 2008] und [Lilienthal 2019] zusammengefasst.

Abb. 1–1Komplexität und ihre Quellen

Im weiteren Verlauf werden wir sehen, dass die Grundlagen, die wir im ersten Teil des Buches einführen, Methoden und Heuristiken für bestimmte in Abbildung 1–1 aufgeführte Komplexitätsquellen anbieten. Wir werden diese Abbildung in den nächsten Abschnitten daher wiedersehen und sie Schritt für Schritt mit weiteren Informationen füllen.

1.2Herkunft der Komplexität: Problem- und Lösungsraum

Die Herkunftsdimension von Komplexität bei der Softwareentwicklung ist in Abbildung 1–1 auf der vertikalen Achse dargestellt. Diese Komplexität entsteht aus dem Wunsch, für eine Domäne eine Software zu bauen; also von der Domäne, einem Teil der wirklichen Welt (dem sog. Problemraum), zu einer Software mit passenden Geschäftsprozessen (in den sog. Lösungsraum) zu kommen. Wir haben somit zwei Quellen:

Problemraum

: die Komplexität der Fachdomäne, für die das Softwaresystem gebaut wurde – die sogenannte

probleminhärente Komplexität

Lösungsraum

: die Komplexität, die in der Umsetzung bei der Modellierung, in der Architektur und bei der Verwendung der gewählten Technologie entsteht – die sogenannte

lösungsabhängige Komplexität

In den letzten Jahrzehnten hat unser Berufsstand bei der Softwareentwicklung immer wieder die Erfahrung gemacht, dass es sehr schwer, wenn nicht gar unmöglich ist, die Komplexität im Problemraum am Anfang eines Projekts abzuschätzen und in einem Pflichtenheft niederzuschreiben. Deshalb dauern Projekte häufig viel länger als geplant, deshalb funktioniert das Wasserfallmodell so schlecht und deshalb sind agile Methoden so populär geworden. Richtig angewandt sind agile Methoden nämlich eine gute Hilfe, denn sie versuchen, die Komplexität im Problemraum in kleineren Häppchen Schritt für Schritt verschränkt mit der Umsetzung zu erfassen.

1.3Art der Komplexität: essenziell vs. akzidentell

In Abbildung 1–1 findet sich auf der horizontalen Dimension die Art der Komplexität mit den beiden Begriffen essenziell und akzidentell. Welche Anteile von Komplexität werden mit diesen beiden Begriffen beschrieben?

Haben wir das weltbeste und erfahrenste Team im Einsatz, dann können wir erwarten, dass wir eine gute Softwarelösung bekommen. Eine Softwarelösung, die eine für das Problem angemessene Komplexität aufweist. Ist die vom Entwicklungsteam gewählte Lösung komplexer als das eigentliche Problem, dann konnte das Entwicklungsteam die essenzielle Komplexität nicht richtig erfassen und die Lösung ist zu komplex, also nicht gut. Dieser Unterschied zwischen besseren und schlechteren Lösungen wird mit essenzieller und akzidenteller Komplexität bezeichnet.

Essenzielle Komplexität nennt man die Art von Komplexität, die im Wesen einer Sache liegt, also Teil seiner Essenz ist. Diese Komplexität lässt sich niemals auflösen oder durch einen besonders guten Entwurf vermeiden. Will man eine Software für eine komplexe Domäne bauen, für eine Domäne, bei der eine hohe Komplexität Teil ihres Wesens – ihrer Essenz – ist, so wird auch die Komplexität in der Software im Lösungsraum hoch ausfallen müssen. So hat eine Softwarelösung für ein Containerterminal eine größere essenzielle Komplexität als eine Software zur Verwaltung von Vereinsmitgliedern in einem Ruderclub.

1.3.1Quellen akzidenteller Komplexität

Akzidentelle Komplexität ist im Gegensatz zur essenziellen nicht notwendig. Sie entsteht aus folgenden Gründen:

aus

Missverständnissen bei der Analyse der Fachdomäne

, sodass uns die Fachdomäne komplexer erscheint, als sie eigentlich ist;

weil wir glauben, dass die Anwender für bestimmte Arbeitsschritte Unterstützung brauchen, obwohl sie eigentlich ganz anders arbeiten, und wir somit

Sachen bauen, die keiner braucht

;

weil wir uns für ein

schlechtes Design und eine schlechte Architektur

entscheiden bzw. Design und Architektur mit der Zeit durch Wartung, Änderung und Unkenntnis erodieren;

weil wir unpassende oder veraltete

Technologie

einsetzen, die ersetzt werden muss, oder weil wir die Technologie nicht so verwenden, wie es eigentlich vorgesehen war.

Wird bei der Entwicklung aus Unkenntnis oder mangelndem Überblick keine einfache Lösung gefunden, so ist das Softwaresystem unnötig komplex. Beispiele hierfür sind: Mehrfachimplementierungen, Einbau nicht benötigter Funktionalität und das Nichtbeachten softwaretechnischer Entwurfsprinzipien. Akzidentelle Komplexität kann von Entwicklern aber auch billigend in Kauf genommen werden, wenn sie z.B. gern neue, aber für das zu bauende Softwaresystem überflüssige Technologie ausprobieren wollen.

1.3.2Entscheidungsbereiche von Softwarearchitektur

Im Foundation Training des iSAQB – International Software Architecture Qualification Board (s. [iSAQB 2023]) –, der Basisausbildung für Softwarearchitekten, werden vier Bereiche definiert, die für die Entscheidungen über die Softwarearchitektur relevant sind: Anforderungsermittlung, Modellbildung, fachliche Architektur und technische Architektur. Diese vier Bereiche bzw. die in diesen Bereichen vorhandenen Methoden und Techniken lassen sich sehr gut auf Abbildung 1–1 anwenden.

Abb. 1–2Komplexität und Architektur

In Abbildung 1–2 können Sie sehen, dass Anforderungsermittlung und Modellbildung im Problemraum sowohl auf der essenziellen als auch auf der akzidentellen Seite ansetzen. Fachliche und technische Architektur wirken auf die essenzielle und akzidentelle Komplexität im Lösungsraum. Die Methoden und Techniken der Anforderungsermittlung, der Modellbildung, der fachlichen und technischen Architektur werden sowohl bei der Neuentwicklung als auch bei der Transformation von Legacy-Systemen eingesetzt, um die essenzielle Komplexität herauszudestillieren und möglichst viel akzidentelle Komplexität in unseren Systemen zu eliminieren (s. Abb. 1–3).

Abb. 1–3Einsatz von Methoden gegen Komplexität

Vollständig werden wir die akzidentelle Komplexität selbst mit den besten Methoden nicht auflösen können, denn wir befinden uns bei der Softwareentwicklung und Softwarewartung in einem kontinuierlichen Lernprozess. Dieser Lernprozess beinhaltet, dass wir Teile der Fachlichkeit und der Technologie immer wieder missverstehen und überflüssige oder schlechte Lösungen für Teilbereiche konzipieren oder implementieren. Deshalb bleibt selbst bei perfekter Umsetzung auf allen Ebenen in Abbildung 1–3 ein Anteil akzidenteller Komplexität bestehen.

1.4Komplexität in Legacy-Systemen

Bei Legacy-Systemen, die schon eine Anzahl von Jahren auf dem Buckel haben und von verschiedensten Generationen von Entwicklern gewartet und verändert worden sind, ist viel akzidentelle Komplexität zu erwarten. Gründe dafür sind:

Die Arbeit der Anwender und damit die Fachdomäne hat sich im Laufe der Jahre verschoben. Neue Funktionalität wurde der Software hinzugefügt, um die Anwender auch bei ihren neuen oder etwas veränderten Aufgaben zu unterstützen. Aber die

Domänenmodellierung

und die

fachliche Modularisierung

des Softwaresystems in der Architektur wurden an diese Verschiebung nicht oder nicht ausreichend angepasst.

Die Entwickler und Architekten des Systems haben über die Jahre aus Zeitdruck, aus Unkenntnis oder aus Desinteresse das

ursprüngliche Design und die Architektur verwässert

und die einzelnen Teile immer stärker miteinander verwoben und so voneinander abhängig gemacht.

Jede

Technologie veraltet

in unserer Disziplin und muss alle 10 bis 15 Jahre durch etwas Neues ersetzt werden. Bei Legacy-Systemen wird der richtige Zeitpunkt häufig verpasst.

Als Evans sein Buch 2004 schrieb, ging es ihm um die Neuentwicklung von Software, also um die Frage: »Was muss ich tun, damit mein neues Softwaresystem domänengetrieben designt ist?« In diesem Buch übertragen wir die Ideen von Domain-Driven Design (DDD) auf Legacy-Systeme. Wir durften in den vergangenen Jahren feststellen, dass wir in DDD Konzepte und Anleitungen finden, die sich für die nötige Neukonzeptionierung und den zum Teil umfassenden Umbau von Legacy-Systemen hervorragend eignen.

Schlüssel dazu ist die schrittweise und behutsame Modernisierung mithilfe einer Kombination aus DDD und weiteren Werkzeugen, die wir im Laufe des Buches einführen.

1.5Struktur dieses Buches

Das Buch besteht neben dieser Einleitung (Kap. 1) – in der wir unseren Begriff von Komplexität erläutert haben – aus drei Teilen, dem Abschluss und einer Website:

Teil I, »Grundlagen für Domain-Driven Transformation«, fasst das benötigte Basiswissen zusammen. Hier zeigen wir, was Domain-Driven Design (Kap. 2) und Collaborative Modeling (Kap. 3) sind und welche Architekturkonzepte (Kap. 4) für das Verständnis dieses Buches wichtig sind. Von diesen drei Kapiteln sollten Sie sich die Abschnitte bzw. Themen heraussuchen, in denen Sie sich nicht firm fühlen.

Im abschließenden Kapitel von Teil I beantworten wir die Frage nach dem richtigen Vorgehen (Kap. 5). Dieses Kapitel ist wichtig für das Gesamtverständnis der nachfolgenden Teile – wir empfehlen es Ihnen daher auf jeden Fall.

Teil II, »Technische, taktische und teamorganisatorische Domain-Driven Transformation«, zeigt, wie das Altsystem auf diese große Verbesserung vorbereitet werden kann. Grundsätzlich lohnt es sich, das Altsystem technisch zu stabilisieren (Kap. 6) und mit taktischer Domain-Driven Transformation die Fachlichkeit im Sourcecode zu stärken (Kap. 7). Und schließlich sollte das Entwicklungsteam Klarheit haben, wie die Teamstrukturen aussehen sollen, wenn man sich auf den Weg einer strategischen Transformation des Altsystems begibt (Kap. 8).

Teil III, »Strategische Domain-Driven Transformation«, stellt das von uns entwickelte Vorgehen zum Zerlegen vor. Das Vorgehen besteht aus vier Schritten: Es beginnt mit dem Wiederentdecken der Fachdomäne (Kap. 9), führt über das Modellieren der fachlichen Soll-Architektur (Kap. 10) und den Abgleich Ist- mit Soll-Architektur (Kap. 11) und endet beim Priorisieren und Durchführen der Umbaumaßnahmen (Kap. 12).

Im »Ausblick: Domain Patterns und ihre Umsetzung in Kontexten« (Kap. 13) stellen wir Ihnen unsere Ideen dazu vor, welche Domänenmuster es gibt, und wie sich das jeweilige Domänenmuster auf die Domain-Driven Transformation auswirkt. Im »Fazit« (Kap. 14) fassen wir das Buch abschließend zusammen.

Um die Transformation durchzuführen, braucht man Domain-Driven Refactorings, die online in einem Katalog gesammelt werden: https://hschwentner.io/domain-driven-refactorings. Wir geben an verschiedenen Stellen im Buch konkrete Referenzen auf das jeweilige zu verwendende Refactoring.

Teil I

Grundlagen für Domain-Driven Transformation

Als Domain-Driven Design – später bekannt als das »Blaue Buch« – von Eric Evans im Jahr 2004 veröffentlicht wurde [Evans 2004], fand es am Anfang wenig Beachtung außerhalb eingeweihter Kreise. Erst als Microservices um 2012 herum als neuer Architekturstil für die Skalierung von großen Softwaresystemen aufkamen, wurde das Buch neu entdeckt. Denn Domain-Driven Design hat nicht nur mit dem sogenannten taktischen Design sinnvolle Entwurfsmuster im Angebot. DDD bietet vielmehr auch eine Methodik an, wie man Domänen in Subdomänen zerlegen und die so entstehende fachliche Struktur auf die Modularisierung von Softwaresystemen – ob nun monolithisch oder eben aus Microservices – übertragen kann: das strategische Design.

An der Menge der Veröffentlichungen, die zu Domain-Driven Design in den Jahren nach 2012 erschienen sind, ist abzulesen, wie wichtig diese Konzepte für die Softwareentwicklung geworden sind. 2013 kam das Buch von Vaughn Vernon heraus: Implementing Domain-Driven Design – genannt das »Rote Buch« [Vernon 2013] –, das einerseits viele gute praktische Tipps zur Implementierung nach DDD gegeben, aber auch angefangen hat, weitere Begriffe und Konzepte hinzuzufügen. 2015 dann erschien Patterns, Principles, and Practices of Domain-Driven Design von Scott Millet und Nick Tune [Millet & Tune 2015]. Vernon hat noch weitere Bücher zu DDD geschrieben (s. [Vernon 2017], [Vernon & Jaskula 2022]), deren Erweiterungen und Erkenntnisse wir im nächsten Kapitel zu DDD (s. Kap. 2) mit aufnehmen. Ein gutes, gerade auf Deutsch erschienenes Buch ist [Khononov 2022].

Event Storming wurde zur gleichen Zeit wie das erste Buch von Vaughn Vernon, 2013, von Alberto Brandolini auf Konferenzen vorgestellt [Brandolini 2021] und u.a. als Unterstützung beim Zerlegen von Software in unabhängige Module bekannt. Wenig später haben Stefan Hofer und Henning angefangen, Domain Storytelling als weitere Methode für das Zerlegen öffentlich zu machen, was schließlich in ihr gleichnamiges Buch mündete (s. [Hofer & Schwentner 2023]). Event Storming und Domain Storytelling gehören zu einer Familie von leichtgewichtigen Methoden, die unter dem Namen Collaborative Modeling bekannt sind. Diesen Methoden widmen wir das Kapitel 3 in diesem Grundlagenteil.

Auch Eric Evans selbst hat weitere Texte zu Domain-Driven Design verfasst: 2013 veröffentlichte er einen 20-seitigen Artikel mit dem Titel Getting Started with DDD When Surrounded by Legacy Systems (s. [Evans 2013]), in dem er Bubble Contexts und vier Strategien vorstellt, wie man sie beim Modernisieren von Legacy-Systemen einsetzen kann. 2015 schrieb er schließlich eine 50-seitige Kurzfassung seines Buches mit dem Titel Domain-Driven Design Reference: Definitions and Pattern Summaries (s. [Evans 2015]). Auch diese Arbeiten haben uns auf unserem Weg bis zu diesem Buch über DDD inspiriert und begleitet und werden an den entsprechenden Stellen wieder auftauchen.

Im Vorwort der DDD Reference bedankt sich Evans bei allen, die schon Beiträge zum Thema DDD geleistet haben, und hofft auf viele neue Artikel, Blogs und Bücher, damit der DDD-Ansatz weiter wächst und gedeiht. Wir hoffen mit unserer Sicht auf Domain-Driven Design und Legacy-Systeme einen weiteren Baustein zum DDD-Ansatz beizutragen.

Die grundlegenden Methoden

In den folgenden drei Grundlagenkapiteln stellen wir Ihnen unser Verständnis von Domain-Driven Design (s. Kap. 2), Collaborative Modeling (s. Kap. 3) und Architekturkonzepte (s. Kap. 4) vor. Diese drei Methoden bzw. Konzepte decken den gesamten Komplexitätsraum ab, den wir am Anfang dieses Überblickskapitels mit Abbildung 1–1 vorgestellt und mit Abbildung 1–2 auf Architektur bezogen haben. In Abbildung I–1 sieht man, wo sie jeweils ansetzen.

Abb. I–1Komplexität und Methoden

Collaborative Modeling deckt den Bereich der Anforderungsermittlung ab, der uns den Zugang zu Geschäftsprozessen, Rollen und Arbeitsgegenständen im Problemraum gibt.

Domain-Driven Design ist für die Komplexitätsbereiche in der Mitte der Abbildung zuständig. DDD hat sowohl im Problembereich als auch im Lösungsbereich Konzepte zu bieten. DDD kümmert sich ausschließlich um die fachlichen Anteile bei der Softwareentwicklung, zu denen die Modellbildung im Problemraum sowie Design und Architektur im Lösungsraum zählen.

Zur Komplexität der Technologie hingegen und zu den Missverständnissen, die beim Einsatz von Technologie zu akzidenteller Komplexität führen können, hält sich Domain-Driven Design bewusst zurück. Das macht DDD so universell einsetzbar und langlebig – es ist nicht technologieabhängig, sondern kümmert sich um den für den Erfolg einer Software entscheidenden Kern: die Fachlichkeit. Denn die Software soll die Anwender bei ihrer fachlichen Arbeit unterstützen – die Technologie ist aus diesem Blickwinkel nur ein Mittel zum Zweck.

Damit die Technologie trotzdem gut gelingt, haben Architekten und Softwareentwickler in den letzten Jahrzehnten Architekturkonzepte beschrieben, die uns helfen, die akzidentelle Komplexität im Lösungsraum zu reduzieren.

Komplexität sichtbar machen mit Architekturdokumentation

Um Komplexität zu erkennen, hilft es, sie sichtbar zu machen. Zur Dokumentation von Architektur gibt es verschiedene Ansätze wie UML, Archimate und Arc42. Wir werden in diesem Buch das C4 Model verwenden, um Ihnen unsere Beispiele nahezubringen, deshalb führen wir die C4-Notation hier am Anfang ein.

Das C4 Model

Für die Visualisierung von Architektur hat sich in den letzten Jahren neben UML und Co. eine leichtgewichtige Variante etabliert: das sogenannte C4 Model (s. [Brown 2023]). Die Idee ist es, sich der Architektur vom Groben zum Feinen zu nähern. Vier sogenannte Levels sind definiert, deren Namen jeweils mit dem Buchstaben C beginnen: Context, Containers, Components, Code.

Auf allen Ebenen des C4 Model können Personen, Architekturelemente und Beziehungen dargestellt werden. Jedes feinere Level beschreibt ein Architekturelement aus dem gröberen Level in seinen Bestandteilen.

Alle Diagramme sollen so selbsterklärend wie möglich sein und eine Legende aufweisen. Die Architekturelemente enthalten typischerweise einen erläuternden Text.

Level 1: Context

Hier wird das System im Ganzen in seiner Umwelt mit Benutzern und verbundenen Systemen dargestellt.

Level 2: Containers

Es wird in das System hineingezoomt und betrachtet, aus welchen Deployment-Einheiten – Container genannt – das System besteht. Ein Container ist ein eigener Prozess. Achtung: Container im C4-Sinne können, müssen aber nicht in Containern im Sinne von Docker laufen.

Level 3: Components

Nun betrachten wir die Teile des einzelnen Containers – die sogenannten Components. Mehrere Components laufen im gleichen Prozess.

Level 4: Code

Schließlich zoomen wir in die einzelne Component hinein und betrachten die Code-Ebene, d.h. aus welchen Klassen und Methoden die Component besteht.

Erste Beispiele für C4-Diagramme werden in den Abbildungen 2–2 und 2–3 zu sehen sein.

Wie weiter?

Werfen wir in diesem ersten Teil des Buches nun also einen Blick auf Domain-Driven Design, Collaborative Modeling und Architekturkonzepte, die wir als Grundlage für Domain-Driven Transformation benötigen.

2Domain-Driven Design

Domain-Driven Design (DDD) ist eine Sicht auf Softwareentwicklung, die die Fachlichkeit ins Zentrum stellt – und zwar nicht nur bei der Anforderungsermittlung durch die Business-Analystin, sondern insbesondere auch bei der Modellierung und Programmierung.

Sprache, Ereignisse, Handlungen, Arbeitsmittel und Strukturen der Domäne werden bewusst in die Software übertragen, damit die Anwenderinnen die bestmögliche Unterstützung für ihre Arbeit bekommen.

2.1DDD-Konzepte gegen Komplexität

Domain-Driven Design kann uns dabei helfen, die akzidentelle Komplexität bei Neuentwicklung zu vermeiden, aber – und das ist das Thema dieses Buches – insbesondere auch die Komplexität von Legacy-Systemen zu verringern.

In Abbildung 2–1 sind die verschiedenen Konzepte aus DDD aufgeführt, die uns helfen, die Komplexität im Problem- und im Lösungsraum auf den essenziellen Anteil zu reduzieren. DDD hilft uns also dabei, von der rechten Spalte, der akzidentellen Komplexität, zurück zur linken Spalte, der essenziellen Komplexität, zu gelangen.

Abb. 2–1Komplexität und DDD

Im Folgenden werden wir die einzelnen Konzepte und Methoden von DDD mit Blick auf Legacy-Software erklären. Wem diese Konzepte und Methoden bereits geläufig sind, dem empfehlen wir nach einem Blick auf das direkt folgende Beispiel einen Sprung zu Kapitel 3, wo es um die Erweiterung von DDD um Methoden für die Anforderungsermittlung gehen wird.

Ein erstes Beispiel: Bestandssoftware im Kino

Als Beispieldomäne nehmen wir ein bisher unabhängiges Programmkino namens Metropolis, wie es in manchen Städten noch existiert. In diesem Programmkino wird für die Planung der Vorstellungen und für den Verkauf der Karten die Legacy-Software CineSmall eingesetzt (s. Abb. 2–2).

Abb. 2–2C4-Kontextsicht auf CineSmall. (Für mehr Informationen über die Notation des C4 Model siehe Abschnitt »Das C4 Model« zu Beginn von Teil I auf Seite 11.)

Bisher verläuft die Arbeit in unserem Programmkino folgendermaßen: Die Kinomanagerin arbeitet jede Woche an der Erstellung eines neuen Wochenplans mit allen Filmen, die in der nächsten Woche gezeigt werden sollen. Solch ein Wochenplan wird immer am Donnerstag herausgegeben und ab der Freigabe in CineSmall können dann Karten für die Vorstellungen der neuen Kinowoche verkauft werden. Der Verkauf der Kinokarten wird von der Kassenmitarbeiterin direkt im Kino durchgeführt. CineSmall bietet ihr dafür Saalpläne für alle Vorstellungen, wo sie für die Kinobesucherinnen Plätze reservieren und Tickets verkaufen kann.

Leider kann unser Programmkino nicht mehr wirtschaftlich arbeiten und die Eignerin muss es an eine große Kinokette verkaufen. Diese Kinokette hat aktuell eine Standardsoftware im Einsatz, die mehr schlecht als recht an die Prozesse der Kinokette angepasst wurde.

Bei der Due-Diligence-Prüfung vor der Übernahme des Programmkinos hat das Management der Kinokette festgestellt, dass CineSmall von seiner Funktionalität her gut zu den Prozessen der Kinokette passen würde. Um das Unternehmen weiterzuentwickeln, beschließt das Management, dass die Kette und weitere dazugekaufte Kinos auf CineSmall umsteigen sollen. Zum Teil sind diese Kinos größer als das Programmkino und zeigen statt Arthouse-Filmen eher Mainstream-Filme.

Diesen Anpassungen ist CineSmall in seiner aktuellen Architektur nicht gewachsen. Die hinzugezogenen technischen Beraterinnen empfehlen dem Management, CineSmall in eine Microservices-Architektur (vgl. Abschnitt 4.5) umbauen zu lassen, damit sowohl Skalierungsanforderungen als auch zusätzliche Funktionalitäten, wie Kinokartenkauf im Web, möglich werden. Um die Architektur von CineSmall auf neue Beine zu stellen, schlagen die Beraterinnen eine Analyse mit Domain-Driven Design vor.

Schauen wir uns die Empfehlungen der Beraterinnen einmal im Detail an!

2.2DDD und die Fachdomäne

Damit Entwicklerinnen eine Software umbauen können, müssen sie die Domäne verstehen – denn in der Software kann nur das richtig umgesetzt werden, was die Entwicklerinnen verstanden haben (s. [Brandolini 2021]). Dieser Lernprozess über die Domäne findet am schnellsten statt, wenn die Entwicklerinnen direkt von den Fachexpertinnen der Domäne lernen können.

Um umfassend zu lernen, benötigen die Entwicklerinnen eine Gruppe von Fachexpertinnen, die unterschiedliche Aufgaben mit dem Softwaresystem oder auch weiteren Systemen durchführen. Nur wenn man alle bzw. einen Großteil der Aufgaben versteht und ihren Zusammenhang kennt, wird der Problemraum, für den die Software gebaut wurde, in seiner Gesamtheit sichtbar.

Eine weitere gute Ansprechpartnerin sollte auch die Product Ownerin sein, die über die Weiterentwicklung und Ausgestaltung ihres Softwaresystems von der fachlichen Seite aus wacht. Bei den Product Ownerinnen kann man meistens die Frage klären, wozu die Software gut ist. Also wie sie zum Erfolg des Unternehmens beiträgt.

Bei unserem kleinen Programmkino mit dem Legacy-System CineSmall stehen uns als Fachanwenderinnen das Kinomanagement und ein oder zwei Kassenmitarbeiterinnen zur Verfügung. Eine echte Product Ownerin gibt es in diesem Fall nicht (mehr), denn die Software wurde vor Jahren von einem externen Unternehmen entwickelt.

Die Mitarbeiterinnen des Kinos interagieren außerdem auch noch mit Personen außerhalb des Kinos (s. Abb. 2–3).

Abb. 2–3C4-Kontextsicht auf CineSmall mit externen Personen

In Abbildung 2–3 sind neben der Kinomanagerin und den Kassenmitarbeiterinnen als interne Mitarbeiterinnen auch die Kinobesucherin sowie Mitarbeiterinnen des Filmverleihs und der Werbeagentur zu sehen.

In der DDD-Literatur beginnt dieser Austausch mit den Fachexpertinnen mit dem Schritt der Modellbildung, d.h., die Entwicklerinnen diskutieren fachliche Begriffe und ihre Verbindungen mit den Fachexpertinnen, um einheitliche Begriffe in einer gemeinsamen Sprache (s. Abschnitt 2.2.1) zu modellieren.

Im nächsten Kapitel zu Collaborative Modeling (s. Kap. 3) werden wir sehen, dass eine Analyse der Prozesse, aus denen die Arbeit der beteiligten Rollen besteht, als vorgeschaltete Anforderungsanalyse die Modellbildung noch effizienter gestalten kann.

2.2.1Ubiquitous Language

DDD fordert, dass alle Beteiligten an einem Softwareprojekt eine gemeinsame fachliche Sprache entwickeln, die sogenannte Ubiquitous Language. Diese gemeinsame Sprache soll auf der Fachsprache der Fachexpertinnen basieren, nicht auf der technischen Sprache der Entwicklerinnen. Ziel dabei ist es, die Fachsprache so zu standardisieren, dass die Fachbegriffe aus dem Problemraum (Domäne) im Lösungsraum (Software) ihre Entsprechung finden können.

DDD empfiehlt, dass diese gemeinsame Sprache während der Laufzeit eines Softwareentwicklungsprojekts überall verwendet wird. Überall bedeutet im Gesprochenen, im Geschriebenen, in Diagrammen und eben auch im Code. Deshalb wird diese Sprache Ubiquitous Language (also allgegenwärtige Sprache) genannt.

In Abbildung 2–4 sehen wir beispielhaft den Begriff »Wochenplan«, der sowohl im Gespräch als auch in den Klassendiagrammen und schließlich auch im Sourcecode auftaucht.

Abb. 2–4Ubiquitous Language: Überall werden die gleichen Worte verwendet.

2.2.1.1Begriffsmodelle

Um sich die Ubiquitous Language zu erarbeiten, benutzt Eric Evans in seinem Buch und seinen Artikeln simple Diagramme, in denen die Fachbegriffe aufgeführt und zueinander in Beziehung gesetzt werden. In einer Workshop-Situation kann man so etwas am Whiteboard oder mit Klebezetteln modellieren.

In unserem ersten DDD-Workshop für das Programmkino taucht eine Reihe von Fachbegriffen auf, die Kandidaten dafür sind, in die Ubiquitous Language aufgenommen zu werden: »Wochenplan«, »Vorstellung«, »Karte«, »Saalplan«, »Sitzplatz« usw. Dabei interessieren uns nicht nur die Substantive, sondern auch die Verben: »anbieten«, »bezahlen«, »planen« usw.

Für unser Kino entsteht in der Diskussion mit den Fachexpertinnen so Schritt für Schritt das Begriffsmodell, das in Abbildung 2–5 zu sehen ist.

Abb. 2–5Ubiquitous Language im Kino: Begriffe

Bei der Arbeit an der Ubiquitous Language müssen die Workshop-Teilnehmerinnen ganz besonders aufmerksam sein, dass sie tatsächlich die Fachsprache der Fachexpertinnen herausdestillieren und nicht eigene vermeintlich fachliche Begriffe in die gemeinsame Sprache einfügen. Wir konnten immer wieder beobachten, dass Workshop-Teilnehmerinnen Synonyme verwendeten, obwohl die Fachexpertinnen diese Begriffe gar nicht in den Mund nahmen.

Im Programmkino-Beispiel hören wir z.B. folgende Fragen:

Dürfen wir statt »Karte« auch die Worte »Kinokarte« oder »Ticket« verwenden? Wird damit dasselbe gemeint?

Ist »Kinoprogramm« das Gleiche wie »Wochenplan«?

Sind »bezahlen« und »kaufen« unterschiedliche Tätigkeiten?

Welche Begriffe die fachlich richtigen sind, können Beraterinnen und Entwicklerinnen nicht allein entscheiden, sondern immer nur in der Diskussion mit den Fachexpertinnen. Durch solche Unachtsamkeiten können im Gespräch mit den Fachexpertinnen Missverständnisse auftreten, die später zu Fehlinterpretationen beim Umbau der Software führen. Die Erarbeitung der Ubiquitous Language erfordert also sehr viel Disziplin von den Workshop-Teilnehmerinnen, um jegliche Art von Sprachverwirrung zu vermeiden.

Die Fachexpertinnen sind sich nicht immer einig und verwenden ebenfalls Synonyme oder eine unscharfe »fachliche Umgangssprache«. Eine Ubiquitous Language herauszuarbeiten, bedeutet daher auch, die Sprache so weit zu formalisieren, dass sie für die Softwareentwicklung verwendbar wird.

2.2.1.2Glossare

Um Sprachverwirrung zu vermeiden, kann es helfen, erläuterungswürdige Begriffe der Ubiquitous Language in Glossareinträgen zu beschreiben. Auch diese können zunächst am Whiteboard oder auf Klebezetteln notiert werden.

Im Programmkino wird das Glossar aus Abbildung 2–6 erstellt.

Abb. 2–6Glossar im Kino

Glossare sind ein sehr altes Mittel, um Begriffe und deren Bedeutung sowie Synonyme zu erfassen. Die gängige Kritik an Glossaren ist, dass sie in der Praxis nicht gepflegt werden und schnell veralten. Wenn man das Glossar allerdings als ein Mittel betrachtet, das dabei hilft, eine Domäne kennenzulernen und Begriffe zu klären, und das später durchaus weggeworfen werden kann, dann leistet es einen wertvollen Beitrag. Wir können den Einsatz von Glossaren zu Beginn einer Transformation daher nur wärmstens empfehlen.

2.2.1.3Verschmutzung der Fachsprache mit technischen Begriffen

Bei der Analyse einer Legacy-Software kommt erschwerend hinzu, dass die in der Legacy-Software enthaltene Fachsprache in den meisten Fällen ohne DDD-Brille und ohne Fachexpertinnen aufgebaut worden ist.

Vielmehr sind in den meisten Legacy-Systemen Unmengen von vermeintlichen Fachbegriffen oder auch fachfremde Abkürzungen zu finden, die erst durch die Entwicklung der Legacy-Software oder den Einsatz einer Standardsoftware Einzug in die Arbeitswelt unserer Fachexpertinnen gehalten haben.

Bei der Diskussion ihrer Arbeit berichtet die Kinomanagerin von zwei Excel-Dateien mit den relativ kryptischen Namen: BPWERB.XLS und MOVIES-8.XLS. Nach einiger Diskussion und unseren Fragen (»Was ist das fachlich?«) wird klar: Ach! Das sind ja eigentlich fachliche Konzepte, die auch einen fachlichen Namen haben, nämlich »Buchungsplan für die Werbung« und »Vorgaben für Filme«. So können wir die beiden Konzepte jeweils mit einem fachlich sinnvollen Namen benennen.

Diese beiden Excel-Dateien haben mit CineSmall selbst nichts zu tun, denn die Kinomanagerin hat bisher keine Möglichkeit, sie in CineSmall zu importieren, sondern schaut sie beim Erstellen des Wochenplans auf ihrem Rechner an. Aber auch solche Begriffe gehören in die Ubiquitous Language.

Bei der Diskussion der Arbeit der Kassenmitarbeiterin stoßen wir außerdem auf einen Begriff, der sich durch die Verwendung von CineSmall von den eigentlichen Fachbegriffen entfernt hatte. Als wir über das Finden und Verkaufen von Plätzen für eine Vorstellung sprechen, sagt die Kassenmitarbeiterin: »Dann gehe ich in die Saalliste und öffne den Saal für die Vorstellung. Da suche ich dann die Plätze.«