Kombination von Domain-Driven Design und Behaviour Driven Development

In meinem letzten Beitrag habe ich erläutert, warum wir Software mit Einfühlungsvermögen schreiben wollen; Software, die für andere verständlich ist. Damit wir Software mit Einfühlungsvermögen erstellen können, müssen wir ein gemeinsames Verständnis für die Bedürfnisse der Benutzer schaffen; die Bedürfnisse, die wir mit unserer Software zu befriedigen versuchen. Praktiken wie Domain Driven Design (DDD) und Behaviour Driven Development (BDD) können uns dabei helfen, dies zu erreichen. Indem wir Feature Mapping (eine Technik aus BDD) verwenden und dieses mit Event Storming (einer Technik aus DDD) verbessern, können wir gleichzeitig ausführbare Spezifikationen und ein Modell für unsere Geschäftsanforderungen erstellen. Auf diese Weise können wir Software und Tests schreiben, die mit dem gemeinsamen Verständnis des Unternehmens übereinstimmen, wodurch wir schneller mehr Wert liefern können.

Straßenlaternen-Effekt

Wenn agile Teams damit beginnen, Anforderungen zu entwickeln, geschieht dies meist im Rahmen von Verfeinerungen. Das Ausmaß, in dem Business-Analysten im Vorfeld funktionale Entwürfe erstellen, nimmt ab, und das ist auch gut so, wenn wir in komplizierten und komplexen Umgebungen arbeiten: Die meisten Entwickler werden große funktionale Entwürfe einfach nicht lesen. Wie Alberto Brandolini einmal sagte: "Das einzige Buch, das Entwickler lesen und das mehr als 50 Seiten umfasst, ist Game of Thrones". Analysten, Domänenexperten, Geschäftsleute, Tester, Ops und/oder funktionale Anwendungsmanager müssen ein gemeinsames Verständnis und eine gemeinsame Denkweise in Bezug auf die Geschäftsanforderungen haben. Hierfür benötigen wir ein umfassendes Fachwissen. Dies ist mit einigen Herausforderungen verbunden. Das größte Problem, das ich in Teams erlebe, ist eine Form der beobachtbaren Voreingenommenheit, die als "Streetlight Effect" bezeichnet wird.

Ein großartiges Beispiel für den "Streetlight Effect" ist der unsichtbare Gorilla. Die meisten Menschen haben vielleicht die unsichtbare Monkey Business Illusion gesehen, bei der Sie zählen müssen, wie oft sich die Spieler im weißen Hemd gegenseitig den Basketball zuwerfen. Während dieses Videos spaziert ein Gorilla auf dem Mond durch den Bildschirm, und 80% der Menschen werden den Gorilla nicht bemerken. Das gleiche Experiment wurde mit Radiologen durchgeführt, die eine bekannte Aufgabe zur Erkennung von Lungenknoten lösen sollten. 83% der Radiologen haben den Gorilla nicht gesehen. Die Wissenschaftler nannten dies "Unaufmerksamkeitsblindheit".

Vorsätzliche Entdeckung

Um dem "Streetlight-Effekt" entgegenzuwirken, wollen wir Deliberate Discovery im Gegensatz zu Accidental Discovery einsetzen. Dan North erklärt den Unterschied in einem schönen Blogbeitrag. Techniken aus DDD und BDD können Teams dabei helfen, dem "Streetlight-Effekt" entgegenzuwirken. BDD-Techniken konzentrieren sich in der Regel mehr auf die Story und arbeiten auf ausführbare Spezifikationen hin, die in automatisierten Tests verwendet werden können. DDD-Techniken hingegen konzentrieren sich eher auf die Modellierung der Software, die wir erstellen. Sowohl in der DDD- als auch in der BDD-Welt gibt es bei diesen Techniken einige Überschneidungen, aber ich stoße nur selten auf eine Situation, in der diese beiden Welten kombiniert werden. Feature Mapping (entwickelt durch BDD) und Event Storming (entwickelt durch DDD) sind beides großartige Techniken, deren Ergebnisse wir nutzen können, um direkt zu unserem Softwarecode und Testcode zu gelangen. Dies hilft uns dabei, Code zu erstellen, der dem gemeinsamen Verständnis unseres Teams entspricht: dem mentalen Modell. Code, der das mentale Modell unseres Teams repräsentiert, ist effektiv, da er weniger Missverständnisse hervorruft und als lebendige Dokumentation dient. So können beispielsweise neue Entwickler in unserem Team den Code durchgehen und ein gutes Gefühl dafür bekommen, worum es in der Domäne geht. Dadurch wird die Zeitspanne, in der ein neuer Entwickler produktiv wird, verkürzt, da der Code verständlicher ist. Wenn jemand aus dem Unternehmen einen Fehler in einem System meldet, kann der Entwickler die vom Unternehmen verwendete Sprache leicht mit dem Code abgleichen und den Fehler viel schneller lösen. Obwohl der anfängliche Aufwand hoch ist, wird die Produktivität gesteigert und diese Technik trägt dazu bei, dass mehr Wert schneller geliefert wird.

Verbessern der Feature-Zuordnung mit Event Storming

Wenn wir uns das Feature Mapping von John Smart ansehen, konzentriert es sich auf einen einfacheren Weg von User Stories zu ausführbaren Akzeptanzkriterien (siehe Abbildung unten). Diese Technik hilft uns, die Sprache der Domäne in unseren Testcode einzubringen und vermittelt eine gute Kenntnis des Geschäftsprozesses. Wir wollen 'Geschichten aus dem wirklichen Leben' hören. Am wichtigsten ist es, diese Geschichten von den Beteiligten aus erster Hand zu erhalten. Wir wollen den Zweck der Geschichte kennen. Wir wollen sie erleben. Aus der Geschichte heraus entdecken und notieren wir die Akteure, den Ablauf und die Aufgaben, die Beispiele und Regeln und gehen dann zu den ausführbaren Spezifikationen über. Die Geschichte, die erzählt wird, ändert sich selten. Die Regeln können sich zwar ändern (z. B. kann ein Online-Händler den Schwellenwert des Warenkorbs für den kostenlosen Versand ändern), aber der Zweck bleibt derselbe. Wenn sich der Zweck ändert, wird es wahrscheinlich eine andere Geschichte sein.

Was beim Feature Mapping fehlt, ist die Modellierung des Zwecks. Sie können verschiedene Modelle für ein und denselben Zweck erstellen und untersuchen. Ein Modell kann sich sogar ändern, während der Zweck derselbe bleibt. Es gibt kein perfektes Modell, alle Modelle sind falsch. Ein Modell ist eine Abstraktion der Realität, die für den Zweck geeignet ist, aber eine Abstraktion wird immer fehlerhaft sein. Wenn wir also mehr Geschichten für denselben Zweck bekommen, kann das Modell, das wir verwenden, unbrauchbar werden. Wir müssen uns also anpassen und neue Modelle finden, die für die neuen Geschichten geeignet sind. Event Storming ist eine von Alberto Brandolini entwickelte Technik, bei der es darum geht, Modelle aus dem Ablauf und den Aufgaben der Story zu erstellen. Mit dieser Technik können wir verschiedene Modelle erstellen. Die Kombination von Event Storming mit Feature Mapping ist wirklich leistungsstark, da Sie sowohl Ihre Beispiele als auch Ihr Modell visualisieren können. Auf diese Weise können wir unser Modell auf der Grundlage unserer Beispiele immer weiter verfeinern. Denn wenn alle Modelle falsch sind, wollen wir Konzepte und Modelle, die nicht passen, loslassen, denn wir brauchen die Möglichkeit,"unsere Lieblinge zu töten". Vor allem, wenn wir ein Modell einige Zeit lang verwenden, kann dies sehr schwierig sein, weil wir uns an das Modell binden können. Dies ist eine der größten Herausforderungen bei der Entwicklung von Software.

Ein laufendes Beispiel

Die Benutzergeschichte und die Akteure

Ich möchte Ihnen ein Beispiel geben. Nehmen wir an, wir haben die Benutzergeschichte des Kaufs von Theaterkarten. Nach dem Feature Mapping beginnen wir mit Schritt 1, dem Erzählen der Geschichte vom Kauf einer Theaterkarte. Der Geschäftsanalytiker wird zum Beispiel erklären, was der Bedarf und der Zweck dieser Geschichte sind. An diesem Punkt hören wir einfach zu, wenn der Analyst die Geschichte erklärt und "Geschichten aus dem wirklichen Leben" erzählt. In Schritt 2 werden wir dann die Akteure beschreiben:

• Der Kunde kauft ein Ticket.
• Das Theater verkauft die Karten.

Machen Sie sich keine allzu großen Sorgen, wir können sie jederzeit ändern.

Event Storming

Für Schritt 3 ist es nun an der Zeit, mit Event Storming zu beginnen. Beim Event Storming gibt es fünf wichtige Konzepte: Befehl (Blau): Entscheidung oder Aktion. Aggregat (Gelb): Lokale Logik Ereignis (Orange): Domänen-Ereignis Richtlinie (Flieder): Reaktive Logik (Wann immer), Listener, Prozessmanager, Saga. Modell lesen (grün): Schlüsselinformationen Der grundlegende Ablauf von Event Storm ist: Command -> Aggregate -> Event -> Read Model oder Policy. Wenn Sie mehr über diese Konzepte wissen möchten, empfehle ich Ihnen, das Buch über Event Storming zu lesen oder einen Workshop Event Storming zu besuchen. Ich werde nicht zu sehr ins Detail gehen, aber gerade so viel, dass Sie folgen können.Wir beginnen also mit Event Storming, einem naiven Ablauf für die Bestellung von Kinokarten, ohne das Aggregat bereits zu definieren. Schreiben Sie zunächst das Ergebnis als Ereignis auf und versuchen Sie, vom Anfang des Ablaufs auf dieses Ereignis hinzuarbeiten.

Das Wichtigste dabei ist, dass jede Diskussion visualisiert werden muss, entweder durch Event Storming oder einfach durch das Zeichnen von Bildern. Beim Event Storming beginnen wir in der Regel damit, Beispiele zu nennen. Diese Beispiele sollten auf einen grünen Klebezettel geschrieben werden und auf der linken Seite Ihres Event Stormings platziert werden. Wir können damit beginnen, unseren Aggregaten einen Namen zu geben. Es kann vorkommen, dass hier bereits mehrere Modelle auftauchen; schreiben Sie sie unter oder neben das andere.

Beispiele und Regeln

Der nächste Schritt ist Schritt 4. Für den Moment werden wir das Example Mapping verwenden, um es einfach zu halten. Das Ziel ist es, so viele Beispiele wie möglich zu erhalten. Wenn Sie tiefer gehen und eine Feature Map erstellen möchten, wäre das das Beste! Mehr darüber erfahren Sie in dem Beitrag über Feature Mapping.

Wenn wir fertig sind, wollen wir ein oder zwei Regeln mit den wichtigsten Szenarien herausgreifen und die anderen nur im Hinterkopf behalten. Es ist an der Zeit, zu unserem Event Storm zurückzukehren und zu prüfen, ob unser Modell gut genug ist, um die Beispiele durchzuspielen. An diesem Punkt werden sich mehrere Verzweigungen und Abläufe abzeichnen. Dies gibt Ihnen die Möglichkeit, Ihr Modell aus verschiedenen Blickwinkeln zu betrachten und weitere Modelle zu erstellen. Wahrscheinlich werden Sie die gleichen Aggregate in der gleichen Bewegung sehen. Jetzt ist es an der Zeit, den Fluss loszulassen und sich der Modellierung unserer Aggregate durch Zustandsmaschinen zuzuwenden.

Vom Ergebnis zum Code

Wie Sie aus dem letzten Bild ersehen können, haben wir Beispiele und Modelle erstellt und diese visualisiert. Aus diesem Ergebnis können wir Software auf der Grundlage unseres Modells und ausführbare Spezifikationen auf der Grundlage unserer Beispiele entwickeln. Die Befehle in einem Event Storm stellen die Aufgaben in der Feature Map dar. Wir können diese verwenden, um den Ablauf für unsere ausführbare Spezifikation zu erstellen. Auf diese Weise schaffen wir eine echte allgegenwärtige Sprache und Denkweise, die sich in unserem Code widerspiegelt. Indem wir die ausführbare Spezifikation und das Modell im Code durchgehen, bekommen wir ein Gefühl für den Zweck des Systems. Außerdem entspricht es der Denk- und Redeweise des Unternehmens. Wir werden schneller mehr Wert liefern! Wenn Sie mehr darüber wissen möchten, schauen Sie sich die Xebia Academy Trainingskurse in BDD oder DDD an. Wenn Sie die Folien meines Vortrags auf der DDD Europe 2018 zu diesem Thema sehen möchten, gehen Sie hier. Im nächsten Beitrag zeige ich Ihnen, wie Sie das Ergebnis nutzen und mit Test Driven Development direkt in Ihren Code implementieren können.