Kolumne

Req4Arcs: Anforderungen mit DDD klären

Gernot Starke, Peter Hruschka

© SuS_Media

In der vorigen Folge haben Sie gesehen, wie wir Überblick über die wesentlichen funktionalen Anforderungen bekommen können – nämlich indem wir von groben Zielen ausgehend die Granularität von Anforderungen verfeinern und dabei Geschäftsprozesse und Ende-zu-Ende-Abläufe (Use Cases oder User Stories) untersuchen. In dieser Folge möchten wir das Thema Domain-driven Design (DDD) aufgreifen und auf dessen Ansätze in puncto „Requirements“ eingehen.

Es heißt doch „Design“?

Zu Recht runzeln Sie die Stirn und fragen sich, warum und wie eine Methode namens „DD Design“ bei der Klärung von Anforderungen helfen soll? Ganz einfach – weil ein Entwurf nur gut und angemessen bezüglich konkreter Anforderungen sein kann. Im Präfix „Domain-driven“ stecken die Anforderungen, die DDD dann im dritten „D“ als Grundlage für Entwurfsentscheidungen bei Software verwendet. Werfen Sie einen Blick auf Abbildung 1, die wir aus der offiziellen DDD-Referenz von Eric Evans übernommen haben. Die Ellipsen sind die methodischen Bausteine (oder Patterns) von DDD und alle gefärbten Ellipsen haben ganz wesentlich mit dem Thema „Anforderungen“ zu tun.

Abb. 1: DDD-Patterns

Abb. 1: DDD-Patterns

Selbst wenn Sie in der Abbildung die Namen der einzelnen Patterns nicht lesen – Sie sehen sofort, dass etwa die Hälfte aller DDD-Praktiken auch mit Anforderungen zu tun hat. Den Kern der DDD-orientierten Anforderungsklärung bildet dabei die Ubiquitous Language (UL), die gemeinsame Sprache von Fachleuten und IT (Kasten: „Ubiquitous Language = allgegenwärtige Sprache). Da stellt sich natürlich die Frage, wie diese Sprache aussieht und wo sie herkommt.

Wie jede natürliche Sprache enthält eine UL Substantive, Verben etc. – das ist banal. Wir können ganz allgemein festhalten, dass Substantive in einer UL oftmals Dinge bedeuten: Produkte, Maschinen, Akteure, Organisationen, Sensoren oder auch Daten/Informationen. Verben einer UL bezeichnen Funktionen, Prozesse, Aktivitäten. Charakteristisch für eine UL ist, dass die verwendeten Begriffe eine besondere Semantik aufweisen, also beispielsweise innerhalb der UL ein „Ding“ eine sehr spezifische Menge an Eigenschaften oder (Gültigkeits-)Regeln besitzt. Sonstige Kategorien von Wörtern einer UL können wir im Moment getrost ignorieren.

Die zweite Frage, woher denn eine UL stammt, ist schon spannender: Die DDD-Literatur verwendet den (leider nichtssagenden) Begriff „Knowledge Crunching“ und erklärt das als „die Kunst, relevante Informationen über die Problemdomäne zu destillieren“ [1]-[3]. So abstrakt hilft uns das erstmal nicht weiter – da müssen wir etwas in die Tiefe bohren:

Ubiquitous Language = allgegenwärtige Sprache

Der sperrige Begriff „ubiquitous“ erklärt sich recht anschaulich über seine lateinische Herkunft „ubique“ (überall). Er bedeutet „allgegenwärtig“ oder „überall verbreitet“. Beispielsweise könnten wir uns über die „ubiquitäre Verbreitung schlechter Anforderungen“ beschweren, wenn wir auf sprachlich hohem Niveau über den Zustand von IT-Projekten jammern wollten.

Im DDD bedeutet „Ubiquitous Language“ das zwischen Fachbereichen und Entwicklungsteam verwendete spezifische Vokabular. Die UL soll grundsätzlich immer zur Kommunikation entsprechender Sachverhalte verwendet werden und sich in Dokumenten, Modellen und insbesondere auch im Code wiederfinden. Das ist eine großartige Idee, allerdings sollten Sie unserer Erfahrung nach niemals in Anwesenheit von FachexpertInnen das Wortmonster „Ubiquitäre Sprache“ verwenden, sondern lieber von „spezifischen Fachbegriffen“ oder „Fachterminologie“ sprechen – es sei denn, die Anwesenden zeigen eine ausgeprägte Vorliebe für lateinische Fremdwörter.

Und zu allem Überfluss sind die Begriffe einer UL im DDD keineswegs so ubiquitär (überall verbreitet), sondern sehr strikt auf jeweils einen einzigen Bounded Context beschränkt. Genau genommen sollten wir demnach von ULWSBC sprechen, der „Ubiquitous Language within a single Bounded Context“. Das allerdings klingt noch viel schlimmer als „ubiquitäre Sprache“.

In jedem Fall gilt für Begriffe einer UL, dass ihre Bedeutung und Gültigkeit auf einen Teil einer Domäne beschränkt ist, den sogenannten Bounded Context (BC). Ein „Kunde“ innerhalb eines BC kann in einem anderen BC auch „Kunde“ heißen, aber eine völlig andere Bedeutung besitzen, andere Attribute haben und anderen Gültigkeitsregeln folgen.

Siehe [2] und die DDD-Referenz für weitere Infos.

Verständnis durch Kommunikation

DDD stellt Kommunikation zwischen Fachleuten und Entwicklungsteams in den Vordergrund. Statt Informationen über Dokumente auszutauschen, sollen diese verschiedenen Personengruppen das oben erwähnte Knowledge Crunching in direkter Kommunikation durchführen, das Wissen über eine Domäne gemeinsam diskutieren und die für das jeweilige IT-System benötigten Aspekte gemeinsam herausarbeiten.

Konkret bedeutet das: Lassen Sie sich von Fachleuten Abläufe und Daten erklären. Diskutieren Sie über Normal- und Spezialfälle, hinterfragen Sie Bezeichnungen und Regeln. Kurz gesagt: Sprechen Sie sämtliche Aspekte der Domäne mit Fachleuten durch. Fragen Sie gründlich und merken Sie sich das entsprechende Fachvokabular in der damit gemeinsam entwickelten Ubiquitous Language. Für solche Gespräche gibt es eine Reihe möglicher Ansatzpunkte:

  • Sie können über Prozesse, Abläufe oder Funktionen einsteigen. Dieses Vorgehen ist den klassischen Analyseansätzen recht ähnlich, die wir in der vorigen Folge dieser Kolumne erläutert haben.
  • Bei vielen DDD-Verfechtern gilt aktuell das Event Storming als bevorzugter Einstieg. Darauf möchten wir gleich noch ein wenig eingehen.
  • Eine sehr visuelle Herangehensweise ist das Domain Storytelling, dem wir die kommende Folge widmen.
  • Wir persönlich haben in vielen kleineren bis mittleren Systemen auch gute Erfahrungen mit dem Einstieg über Daten und Datenstrukturen gemacht – das klassische Datenmodell hat jedoch in der DDD-Community einen eher schlechten Ruf (aus unserer Sicht nicht berechtigt – aber diese Diskussion würde den Rahmen dieser Folge sprengen).

Unserer Erfahrung nach ist es relativ egal, über welchen Weg Sie in die Diskussion mit Fachleuten einsteigen – Hauptsache, Sie gewinnen ein fundiertes Verständnis sowohl über statische als auch über dynamische Aspekte eines Problembereichs. Die DDD-Welt ist sich übrigens einig darüber, dass sich die auf diese Weise entwickelte UL im Laufe der Zeit verändern und weiterentwickeln wird: Sie werden während der Entwicklung von Systemen immer mehr Verständnis für die Domäne gewinnen und damit höchst wahrscheinlich auch die UL immer weiter anpassen.

Aber lassen Sie uns noch einen kleinen Ausflug in die Welt der so genannten Domain Events unternehmen – einem aktuellen Trend im DDD.

Über Domain Events zur UL

Schon in den 70er Jahren des letzten Jahrhunderts (also schon sehr lange her) haben Methoden zur System- und Anforderungsanalyse (etwa [4]) vorgeschlagen, eine Domäne über die innerhalb der Domäne auftretenden Ereignisse zu erarbeiten. Im Rahmen des DDD hat der kluge Italiener Alberto Brandolini diese Ideen aufgegriffen und um konkrete Hinweise zur interaktiven Durchführung als Workshops erweitert. Dann hat er dieser Art von Workshops den griffigen Namen Event Storming gegeben und damit sowohl statische als auch dynamische Aspekte von Domänen zusammengebracht.

Event-Storming-Workshops funktionieren interaktiv: TeilnehmerInnen schreiben fachliche „Ereignisse“ (Domain Events) auf Post-its und bringen diese Ereignisse in die sachlich korrekte Reihenfolge. Techies (bzw. Sie als Architekten) hinterfragen dabei die genaue Bedeutung solcher Events und klären ihre Vor- und Nachbedingungen. Insbesondere die offene Diskussion über fachliche Details zwischen Fachleuten und IT während solcher Event-Storming-Workshops bringt oftmals signifikant verbessertes gemeinsames Verständnis in komplexe Fachlichkeit. Weitere Details würden den Rahmen unserer Kolumne sprengen – aber die Klärung fachlicher Sachverhalte auf Basis von Events halten wir für hilfreich (was daran liegen mag, dass wir bereits Structured Design [4] gut fanden!).

Fazit

Domain-driven Design ist viel mehr als nur Design. Nutzen Sie Ansätze wie Event Storming als interaktive Formate zur Erarbeitung und Klärung von Anforderungen – das wird Ihnen garantiert helfen, Ihre fachlichen Stakeholder besser zu verstehen. Möge die Macht guter Anforderungen mit Ihnen sein!

Geschrieben von
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: