Domain Driven Design meets Requirements Engineering

Domain Driven Design meets Requirements Engineering

Die zunehmende Komplexität von Softwaresystemen erfordert neue, moderne und andersartige Vorgehensweisen. So gewinnt Domain Driven Design immer mehr an Aufmerksamkeit, da dieser Ansatz viel mehr als eine Hilfestellung zur Entwicklung von Microservices ist.

Domain Driven Design ist zwar eine Vorgehensweise für das Design von Softwarearchitekturen, bietet aber auch in der Disziplin Requirements Engineering viel Potenzial, was insbesondere folgendes Zitat von Dr. Ute Heimann zum Ausdruck bringt: „Der langlebigste und wichtigste Teil eines Systems ist die fachliche Aufgabenstellung. Software muss sich auf diese Aufgabenstellung konzentrieren und erst in zweiter Linie technologische Fragestellungen lösen.“

Spätestens jetzt sollte ein guter Requirements Engineer Aufmerksamkeit walten lassen.

Was ist Domain Driven Design?

Domain Driven Design bietet eine Methodik, bei der Fachexpertinnen und -experten sowie Entwicklerinnen und Entwickler gemeinsam die Fachlichkeit designen. Die Fachlichkeit wird dabei zum Gegenstand enger, beidseitiger Zusammenarbeit, da der primäre Fokus des Projekts auf die Fachdomänen sowie deren Domänenlogik gelegt wird. Statt technologischer Entscheidungen rückt die Fachlichkeit ins Zentrum des Softwareentwicklungsprozesses. Dabei werden fachliche Sachverhalte bewusst von technologischen Entscheidungen entkoppelt.

Das wichtigste Ziel des Ansatzes ist die Förderung der kreativen Zusammenarbeit zwischen technischen und fachlichen Domänenexpertinnen und -experten, um das konzeptionelle Modell iterativ zu verfeinern. Es ist ein Verfahren, das die Modularisierung von Software auf Basis der Fachlichkeit stringent ermöglicht, indem es umfangreiche Systeme in abgeschlossene Einheiten aufteilt (Bounded Contexts) und den Code mit der Fachlichkeit verbindet. Gerade bei steigender Komplexität von Softwaresystemen bietet dieser Ansatz sehr gute Möglichkeiten, der Komplexität angemessen zu begegnen.

Komplexität verlangt ebenso nach Organisation. Domain Driven Design behandelt diesen Aspekt, indem es Methoden zur Reflexion der Beziehungen und Abhängigkeiten zwischen den Software-Modulen sowie den umsetzenden Teams definiert.

Event Storming – das Feld von hinten aufräumen

Event Storming wurde von Alberto Brandolini im Kontext von Domain Driven Design erfunden und ist ein interaktiver Workshop mit dem Ziel, Software Developer sowie Fachexpertinnen und -experten zusammenzubringen, damit sie voneinander lernen und gemeinsam die Logik einer Fachdomäne gestalten.

In der Requirements-Engineering-Community ist Event Storming jedoch kaum bekannt, obwohl es eine sehr leichtgewichtige Brainstorming-Methode ist, um schnell einen Überblick über den gesamten in der Software abzubildenden Geschäftsprozess zu erhalten. Event Storming ist darüber hinaus als Methode zur Anforderungsaufnahme und -analyse hervorragend geeignet, da es keine Modellierungskenntnisse voraussetzt und kaum Vorbereitung benötigt wird.

Beim Event Storming werden zunächst alle relevanten Geschäftsereignisse (Events) zusammengetragen und in die richtige Reihenfolge gebracht. Dabei wird bereits früh darauf geachtet, dass alle Beteiligten dieselbe Sprache sprechen. Homonyme und Synonyme werden identifiziert und vereinheitlicht. Anschließend wird analysiert, was passieren muss, damit ein Event eintritt. Das können beispielsweise Kommandos vom User, Regelwerke oder eine Entscheidung aus einem Drittsystem sein. Basierend darauf lassen sich Geschäftsprozesse, Datenobjekte und -aggregate sowie die benötigten Informationen auf den Nutzeroberflächen (View Models) ableiten.

Die Events mit ihren Auslösern werden in verschiedene Bereiche geclustert und in Fach- und Subdomänen zusammengefasst, wobei die Zeitlinie nun vernachlässigt werden kann. Ausgehend von den Subdomains können dann die Kontextgrenzen sowie -zusammenhänge und Abhängigkeiten definiert werden. Das Ergebnis ist die Grundlage für das Domänenmodell sowie für einen ersten Softwareentwurf.

Event Storming ermöglicht darüber hinaus das frühzeitige Erkennen von Risiken, seltsam gestalteten Geschäftsprozessen und Know-how-Lücken. Alle kritischen Bereiche, Schlüsselfeatures, Risiken und Möglichkeiten für Verbesserungen werden entsprechend markiert. So bleiben anschließende Überraschungen aus.

Das System bekommt damit eine gute, wartbare Struktur und die Anzahl an Refactorings wird geringer als ohne das im Event Storming erworbene Wissen.

Wie kann ein Requirements Engineer beim Domain-Driven-Design-Ansatz unterstützen?

Die Antwort liegt durch das Zitat von Dr. Ute Heimann im Grunde auf der Hand: Der Fokus liegt auf der Fachlichkeit, nicht auf der Technologie. Infolgedessen kann sich ein Requirements Engineer auch ohne tieferen, technologischen Background in die Vorgehensweise einarbeiten und hervorragend unterstützen.

Im üblichen Tagesgeschäft arbeitet ein Requirements Engineer eng mit Fachleuten zusammen, um die Ziele und Geschäftsanforderungen zu identifizieren und zu erfassen. Auch das Erstellen einer Kontextübersicht sowie das Definieren der Kontextgrenzen gehört zu seinen Aufgaben.

Indem er sich mit dem Kernkonzept von Domain Driven Design auseinandersetzt, wird er befähigt, das Domänenmodell zusammen mit der Architektin oder dem Architekten zu erstellen und die Fachdomänenlogik mithilfe der Muster und Prinzipien von Domain Driven Design zu modellieren. Dabei kann der Requirements Engineer sicherstellen, dass das Design an den Geschäftszielen ausgerichtet ist und die Anforderungen des Projekts erfüllt.

Auch beim Definieren der ubiquitären Sprache kann der Requirements Engineer mit dem Erstellen eines Glossars helfen, damit die Sprache vom gesamten Team verstanden und gesprochen wird.

Event Storming geht dabei in den Standardmethodenkoffer eines Requirements Engineer über, sodass direkt zum Beginn des Projektes die Vorgehensweise an Domain Driven Design ausgerichtet wird, unsere Kundinnen und Kunden darin geschult werden und das Prinzip von Domain Driven Design verstehen.

Ein Requirements Engineer ist weiterhin dafür zuständig, das Projekt zu strukturieren, beispielsweise in Form von Epics und Features sowie Story Maps. Die ermittelten Fachdomänen sollten sich darin wiederfinden, sodass alle Projektbeteiligten eine einheitliche Struktur in den verschiedenen Artefakten sehen und das Verständnis für das Domänenmodell gefördert wird.

Fazit

Domain Driven Design hat sehr viel Potenzial, um komplexe und umfangreiche Projekte zu überblicken und in handhabbare Einheiten zu clustern. Indem sich ein Requirements Engineer mit dieser Vorgehensweise auseinandersetzt und seine Aufgaben im Projekt daran anpasst, kann er einen wertvollen Beitrag leisten, komplexe fachliche Zusammenhänge zu durchdringen und Hand in Hand mit der Architektur ein gut durchdachtes System zu entwickeln.