Autoren

Matthias Eschhold

Nils Hyoma

Enable Domain-Driven Design mit Gamification

Domain-Driven Design Cards (DDD-Cards) ist eine gamifizierte methodische Unterstützung für strategisches und taktisches Domain-Driven Design.

DDD-Cards ist ein gemeinschaftliches Projekt mit nilsbert. DDD-Cards beinhalten das Context Mapping, das Strategic Classification, das Bounded Context sowie das Tactical Architecture Game spielen.

Enabling und Enabler Teams

Der Ansatz Team Topologies beschreibt Enabler-Teams mit der Aufgabe andere Teams dabei zu unterstützen, ihre Kernaufgaben erfolgreich durchzuführen. Diese produkt- oder wertstromorientierten Teams (Stream-Aligned Teams) fokussieren sich auf die stetige Lieferung von Geschäftswert. Auch diese Teams müssen ihre Arbeitsweise und fachliche Expertise weiterentwickeln, um ihre Leistungsfähigkeit zu sichern oder zu steigern.

Hier kommen Enabler-Teams ins Spiel: Sie bringen tiefgehende Fachexpertise ein und arbeiten temporär mit Stream-Aligned Teams zusammen.

Beispiele hierfür sind:

• Aufbau eines Application Performance Monitoring

• Etablierung des Vorgehen Test-Driven Development

• Aufbau einer modernen Continuous Delivery Pipeline

• Etablierung von Behavior-Driven Development

• Coaching und Consulting im Bereich der Application Security

• Coaching und Consulting im Bereich Softwarearchitektur

• Initiale Begleitung bei umfangreichen Architekturmodernisierungen

• Begleitung bei der Einführung von Domain-Driven Design

• ...

DDD-Cards ist ein Werkzeug für Enabler-Teams oder andere Personen / Rollen, um bei der Einführung von Domain-Driven Design zu unterstützen.

Gamification

Gamification überträgt Spielprinzipien auf andere Kontexte, um Motivation, Kreativität und Interaktion zu steigern. Ein Erfolgsfaktor ist die intrinsische Motivation sowie der natürliche Spieltrieb von Menschen, gewünschte Verhaltensweisen auszuführen, Aufgaben zu erledigen oder Ziele zu erreichen.

Die DDD-Cards stellen Teams vor Herausforderungen, die sie gemeinsam meistern müssen. Dies geschieht in Form von Missionen, die im Spielverlauf abgeschlossen werden müssen.

Ein weiterer wichtiger Aspekt von Domain-Driven Design Cards ist das Ziel, alle Mitglieder der Gruppe gleichwertig zu involvieren, unabhängig von ihrem Wissensstand und Charaktertyp. Dies trägt darüber hinaus zu den Zielen der Domain-Driven Design Philosophie bei, die eine Kultur des breiten gemeinsamen Verständnisses und der Zusammenarbeit anstrebt. Domain-Driven Design Cards basieren auf der Annahme, dass in der Realität selten eine Gruppe existiert, die durchgehend über tiefes Wissen im Bereich DDD verfügt. Daher ist die Zielsetzung von Domain-Driven Design Cards, dass die Nutzung auch ohne spezielle Expertise möglich ist. Die Spieler/innen werden durch die Spielkarten, durch eine Expert/in in DDD sowie eine Moderator/in unterstützt. In Bezug auf den Ansatz Team Topologies wird diese Aufgabe von Enablern übernommen.

Enabling von Domain-Driven Design mittels Domain-Driven Design Cards

DDD-Cards sind ein spielerischer Ansatz, um die Prinzipien und Konzepte von Domain-Driven Design zu vermitteln und anzuwenden. Dies erfolgt über fünf für sich stehende Spiele, die in Summe die wichtigsten Kernelemente von Domain-Driven Design über den gesamten Softwareentwicklungsprozess unterstützen.

Bounded Context Game

Definition von Subdomänen und Bounded Contexts anhand visualisierten Fachwissens und DDD-Heuristiken.

Strategic Classification Game

Bewertung der strategischen Bedeutung sowie Ableitung einer Handlungsstrategie für Subdomänen bzw. Bounded Contexts.

Context Mapping Game

Finden und Definieren von Abhängigkeiten zwischen Bounded Context auf Basis der Methode Context Mapping.

Tactical Architecture Game - Architecture Pattern

Gemeinsame Entscheidung für ein taktisches Architekturmuster.

Tactical Architecture Game - Starting Architecture Decisions

Finden eines gemeinsamen Architekturplans für die Umsetzung von Bounded Contexts auf taktischer Architekturebene auf Basis von Architecture Decision Records.

Jedes Spiel fördert Kommunikation, Wissensaustausch und Wissenserweiterung. Dies verspricht gute Entscheidungen auf der jeweilige Architekturebene unter Berücksichtigung aller relevanter Perspektiven und fördert eine Team-Vision und ein Wir-Gefühl.

Bewusste Architekturentscheidungen als Erfolgsfaktor

Every voice shapes the system!

- Kenny Baas-Schwegler

Die Summe an Architekturentscheidungen prägen die Architektur eines Systems. Implizit und nicht kommunizierte Architekturentscheidungen haben oft eine negative Auswirkung auf die Qualität des Systems. Bewusst getroffene Entscheidungen im Entwicklungsteam sind jedoch ein mächtiges Mittel um Lösungsstrategien im Team konsistent und nachhaltig anzuwenden.

Der Aspekt des Enabling bezieht sich an dieser Stelle darauf, dass dem Team Wissen, Rahmen und Raum für gemeinsame Architekturentscheidungen bereitgestellt wird. Das Ziel im Hinblick auf das Tactical Architecture Game eine breite Transparenz und Commitment im Team über die taktische Softwarearchitektur eines Bounded Context oder Softwaresystem.

Der folgende Abschnitt beschreibt drei fundamentale Fragen, die ein Team in Form von Architekturentscheidungen beantworten muss.

Durch Grundsatzentscheidungen, wie das Architekturmuster oder die Anwendung des taktischen DDD, manifestieren sich weiche Vorgaben (Soft Standard) für die Architektur.

Diese Vorgaben sind für die Implementierungsebene zu abstrakt, und ohne weitere gemeinsame Entscheidungsfindung ist die Erreichung einer konsistenten Implementierung und die damit verbundenen Qualitätsziele Wartbarkeit, Erweiterbarkeit und Flexibilität, nicht möglich.

Die unterschiedlichen Ausprägungen des Tactical Architecture Game fördern die kollaborative Entscheidungsfindung im Team für die grundlegenden Fragestellungen 1-3.

Konstruktionsplan für ein Architekturmuster

Der Konstruktionsplan ergibt sich durch ein Set von taktischen Architekturentscheidungen. Die Entscheidungen beschreiben, wie das Architekturmuster konkret angewendet wird. Die Entscheidungen stellen richtungsweisende Leitplanken der taktischen Architektur dar, auf die ein Team committet sein muss.

Starting Architecture Decisions für domänenzentrierte Architekturmuster

Die Starting Tactical Architecture Decisions verteilen sich über vier Entscheidungskategorien:

1. Domänenkern
2. Anwendungsfälle
3. Mappings
4. Modularisierung

Starting Architecture Decisions für vertikal geschichtete Architekturmuster

Coming soon...

Entscheidungskategorie Domänenkern

Der Domänenkern beschreibt den fachlichen Kern des Systems im Inneren der domänenzentrierten Architekturmodelle und besteht aus Domänenmodell, -logik sowie -regeln.

Einordnung in die domänenzentrischen Architekturmuster

Architekturentscheidung #1: Nach welchem Prinzip wird das Domänenmodell implementiert?

Vorbedingung

Keine

Soft Standard

Mit der Entscheidung für DDD wird das Ziel verfolgt, ein Domänenmodell zu implementieren. Dabei ist das Aggregate, Entity und Value Object Muster zu verwenden.

Entscheidungskontext

Für die Implementierung eines Domänenmodells muss die Grundsatzentscheidung zwischen dem Rich Domain Model (1.1) und dem Anemic Domain Model (1.2) getroffen werden.

Diese Entscheidung legt fest, wie das Domänenmodell implementiert wird und an welchen Stellen Geschäftslogik und -regeln verortet werden.

Das Rich Domain Model besagt, dass die Fachlogik im Domänenobjekt (Aggregate, Entity, Value Object) implementiert wird. Dadurch wird eine ausdrucksstarke Benennung der Methoden ermöglicht, die auf der Fachlichkeit basiert (im vgl. zu set-Methoden). Eine spezielle Form des Verhaltens findet sich in der implementierung von Domänenobjekt-bezogenen Geschäftsregeln.

Ein Anemic Domain Model enthält nur die Eigenschaften sowie dazugehörige getter und setter. Fachlogik und Validierung werden ausschließlich in Domain Services implementiert. Das Anemic Domain Model gilt auch als Anti-Pattern, da dies oft zu einem Verlust der Fachsprache im Modell und zu unnötige Komplexität führt im vgl. dazu die Fachlichkeit im Modell abzubilden.

Der Mittelweg stellt das Moderately Rich Domain Model (1.3) dar. Hier werden Daten und Geschäftsregeln im Objekt gekapselt, weitere Fachlogik wird in Domain Services ausgelagert.

Risiko wenn diese Entscheidung nicht aktiv getroffen wird

• Es entstehen uneinheitliche Implementierungen des Domänenmodells
• Die Fachlichkeit wird nicht ausreichend im Modell abgebildet und unnötige technische Komplexität entsteht

Entscheidungsalternativen

Architekturentscheidung #2: Wie soll das Value Object Muster in der Implementierung angewendet werden?

Vorbedingung

Annahme
Wird eine 1.3 Anemic Domain Model eingesetzt, wird die Implementierung von Value Objects als nicht wertstiftend angesehen. Die Entscheidung #2 muss in diesem Fall nicht getroffen werden.

Entscheidungskontext

Wird dem Rich oder dem Moderately Rich Domain Model gefolgt, entsteht in Teams i.d.R. die Frage, ob jeder Fachwert als Value Object implementiert werden soll, denn in einem komplexen Aggregate können potenziell viele Value Objects entstehen.

In der Literatur gibt es auf deiner eine Seite die Empfehlung einen fachlichen Wert immer als Value Object zu implementieren. Auf der anderen Seite existiert ein großen vielfalt von unterschiedlichen Implementierungsbeispiele von Value Objects. Wird diese Aussage mit den Codebeispielen in Verbindung gebracht, wird deutlich, dass die Empfehlung nicht bedeutet, dass keine primitiven Datentypen mehr verwendet werden dürfen.

Dennoch ist das, das eine extrem der Entscheidung: Jeder Fachwert wird mittels Value Object Muster implementiert. (2.1) Ein Value Object wird angewendet mit den Zielen,

• Die Fachliche Ausdrucksstärke in der Paketstruktur und auf Klassenebene zu erhöhen
• Eine Fachliche Typisierung durch die Eigenschaft der Selbst-Validierung zu realisieren
• Fachliche Logik bezogen auf den Fachwert zu kapseln
• Die Seiteneffektfreiheit durch die Eigenschaft der Immutabilität, insbesondere bei Paralellität, zu erhöhen

Es gibt jedoch auch Fälle, in denen die Implementierung eines Fachwertes als Value Object nicht notwendig ist. Dies ist dann der Fall, wenn die fachliche Typisierung und Selbst-Validierung und die Kapselung von Fachlogik nicht notwendig ist. Ein pragmatischer Ansatz, Value Objects nur zu verwenden, wenn diese Eigenschaften notwendig sind (2.2), ist valide und in Abhängigkeit der konkreten fachlichen Anforderungen zu betrachten.

Auf Value Objects zu verzichten und ausschließlich primitive Datentypen zu verwenden (2.3), ist ebenfalls eine Möglichkeit, wird jedoch in der DDD-Community als Anti-Pattern bewertet. Dies ist insbesondere bei komplexen Aggregates mit viel und/oder komplexen Geschäftsregeln und Logik der Fall, dann dies dann vollständig im Aggregate oder in einer Entity implementiert werden muss.

Risiko, wenn diese Entscheidung nicht aktiv getroffen wird

• Es entstehen uneinheitliche Implementierungen der Fachwerte und in der Konsequenz auch die Prüfung von Geschäftsregeln
• Es entstehen widersprüchlich Implementierungsvarianten und die Verständlichkeit des Codes wird erschwert
• Entwickler/innen ist unklar, welche Implementierungsvariante wann für einen Fachwert zu wählen ist

Entscheidungsalternativen

Architekturentscheidung #3: Wie wird die fachliche Konsistenz bei Verwendung des Anemic Domain Model gesichert?

Vorbedingung

Entscheidungskontext

Wird das Anemic Domain Model angewendet, muss für die Invarianten und Verhalten ein anderes Element als die Domänenobjekte selbst gefunden werden. Eine Möglichkeit hierfür ist der Domain Service (3.1), jedoch würde dies dazu führen, dass die Verantwortung für Fachlogik und fachliche Validierung in einem Muster verortet wird. Bei erhöhter fachlicher Komplexität, empfiehlt sich daher die Einführung eines neuen Elements in der Mustersprache, wie z.B. ein Validator (3.2).

Risiko, wenn diese Entscheidung nicht aktiv getroffen wird

• Es entstehen uneinheitliche Implementierungen der Fachwerte und in der Konsequenz auch die Prüfung von Geschäftsregeln
• Dies reduziert die Verständlichkeit und Entwickler/innen ist unklar, welche Implementierungsvariante wann für einen Fachwert zu wählen ist

Entscheidungsalternativen

Architekturentscheidung #4: Wie werden Domänenobjekt-bezogene Geschäftsregeln implementiert?

Vorbedingung

Keine

Entscheidungskontext

Unabhängig davon, in welchem Element der Mustersprache die Implementierung von Geschäftsregeln verortet wird, stellt sich die Frage wie die Implementierung erfolgen soll.

Eine Möglichkeit ist die Implementierung der Geschäftsregeln nativ mit den Mitteln der genutzten Programmiersprache (4.1).

Eine weitere Möglichkeit ist die Implementierung mit einer proprietären Abstraktion zur Wiederverwendung von Validierungsregeln (4.2). Diese Abstraktion koppelt auf lange Sicht, fachliche Komponenten des Systems und sollte daher mit Bedacht eingesetzt werden.

Eine dritte Möglichkeit ist der Einsatz einer Third-Party Library (4.3), die Out-of-the-Box Validierungsregeln enthält. Dies kann die Implementierung von Geschäftsregeln beschleunigen. Jedoch sollte die Abhängigkeit zur Library hinsichtlich Funktionsumfang, Stabilität, Erweiterbarkeit und Einfachheit bewertet werden.

Risiko, wenn diese Entscheidung nicht aktiv getroffen wird

• Es entstehen uneinheitliche und evtl. widersprüchliche Implementierungen für die Prüfung von Geschäftsregeln
• Dies reduziert die Verständlichkeit und den Entwickler/innen ist unklar, welche Implementierungsvariante wann für die Implementierung von Geschäftsregeln zu verwenden ist
• Mehrere Libraries werden für denselben Zweck verwendet, was zu einer unnötigen Komplexität führt
• Ein Mix aus nativer Implementierung und Third-Party Libraries führt zu einer schwer nachvollziehbaren Verflechtung von Regeln, die keine fachliche Konsistenz gewährleisten

Entscheidungsalternativen

Architekturentscheidung #5: Welche Strategie der Objekterzeugung, wird für komplexe Fachobjekte verwendet?

Vorbedingung

Keine

Entscheidungskontext

Die Mustersprache des taktischen Designs beschreibt die Factory (5.1), die die Verantwortung für die Objekterzeugung übernimmt, wenn dies nicht mehr durch einen einfachen Konstruktor (5.4) am Objekt selbst möglich ist.

Als Ergänzung oder Alternative zur Factory kann das Builder-Pattern (5.2) eingesetzt werden. Als Ergänzung bzw. Alternative zum Konstruktor, ist Static Factory Method Pattern (5.3) zielführend.

In der Regel gibt es nicht den einen Erzeugungsprozess für Domänenobjekte. Folglich ist die Kombination der Lösungsstrategien für jeweilige passende Einsatzszenarien ein guter Weg. Wann welche Muster eingesetzt wird, sollte basierend auf einem gemeinsamen Verständnis in der Architekturentscheidung festgehalten werden.

Szenarien

Im Folgenden sind vier Szenarien aufgeführt, die Objekterzeugung in domänenzentrischen Architekturmuster bedingen.

1. Ein User führt Anwendungsfälle aus, bei denen das Domänenobjekt erzeugt werden muss
2. Der Zustand eines Domänenobjektes muss aus dem Speicher gelesen werden
3. Der Zustand eines Domänenobjektes ergibt sich aus unterschiedlichen Quellen (z.B. Speicher und externer Service)
4. Die Geschäftslogik bedingt die (Neu-)Erzeugung von Domänenobjekten als Bestandteil der Kontrollfluss der Domänenlogik

Risiko

• Eine uneinheitliche und potenziell widersprüchliche Verwendung der Erzeugungsmuster erhöht die strukturelle Komplexität
• Dies reduziert die Verständlichkeit und Entwickler/innen ist unklar, welches Erzeugungsmuster für einen Fachwert zu wählen ist, was zu weiteren Abweichungen und Varianten führt

Entscheidungsalternativen

Entscheidungskategorie Anwendungsfälle

@ToDo

Geschäftsregeln stellen im Kontext der Entscheidungskategorie Anwendungsfälle anwendungsfall-spezifische Regeln dar.

Einordnung in die domänenzentrischen Architekturmuster

Architekturentscheidung #6: Wie werden Use Cases geschnitten?

Vorbedingung

Keine

Entscheidungskontext

Use Cases sind Schnittstellen der fachlichen Applikation und werden aus der Perspektive der Domäne definiert. Dabei können verschiedene Heuristiken zum Einsatz kommen, und keine Heuristik ist per se die beste.

Ziel ist es im Team zu definieren, welche Heuristik überwiegend oder in Abhängigkeit eines bestimmten Szenarios verwendet werden soll. Diese Szenarien der Anwendung sind auf Basis eines gemeinsamen Verständnisses in der Architekturentscheidung zu dokumentieren.

Risiko, wenn diese Entscheidung nicht aktiv getroffen wird

• Es entstehen uneinheitliche Varianten der Implementierung und Benennung von Use Cases
• Dies reduziert die Verständlichkeit und Entwickler/innen ist unklar, welche Implementierungsvariante wann für einen Use Case zu wählen ist

Entscheidungsalternativen

Entscheidungskategorie Mappings

Die Entscheidungen über den Einsatz von Mapping-Strategien beeinflusst den Kopplungsgrad des Systems im Gesamtbild. Mappings können jedoch auch Overhead darstellen, weshalb eine gute Balance abgestimmt auf die Anforderungen notwendig ist.

Einordnung in die domänenzentrischen Architekturmuster

Architekturentscheidung #7: Welche Mapping-Strategie wird als Default-Strategie verwendet und für welche Szenarien eignen sich alternative Strategien?

Vorbedingung

Keine

Entscheidungskontext

@ToDo

Risiko, wenn diese Entscheidung nicht aktiv getroffen wird

@ToDo

Entscheidungsalternativen

Architekturentscheidung #8: Wie werden Mappings implementiert?

Entscheidungskontext

Für die Two-Way und die Full Mapping Strategie stellt sich die Frage, wie Mappings implementiert werden sollen. Eine einheitliche Lösungsstrategie wird empfohlen, um die Komplexität in der Implementierung nicht unnötig zu erhöhen. Jede Variante hat Vor- und Nachteile, und letztendlich muss sie auch den Vorlieben des Teams entsprechen.

Risiko, wenn diese Entscheidung nicht aktiv getroffen wird

@ToDo

Entscheidungsalternativen

Entscheidungskategorie Modularisierung

Starting Architecture Decisions der Entscheidungskategorie Modularisierung haben übergreifenden Charakter und gelten in allen domänenzentrischen Architekturmuster auf gleiche Weise.

Architekturentscheidung #9: Vertikale vs horizontale Schichtung

Vorbedingung

Keine

Entscheidungskontext

@ToDo

Risiko, wenn diese Entscheidung nicht aktiv getroffen wird

@ToDo

Entscheidungsalternativen

Architekturentscheidung #10: Wie wird Modularisierung umgesetzt?

Vorbedingung

Entscheidungskontext

@ToDo

Risiko, wenn diese Entscheidung nicht aktiv getroffen wird

@ToDo

Entscheidungsalternativen

Architekturentscheidung #11: Wie werden fachliche Module strukturiert?

Vorbedingung

Entscheidungskontext

Das fachliche Modul wird abgeleitet auf Basis eines Aggregate (Root Entity). Innerhalb dieses Moduls werden die Verantwortungsbereiche (Ring, Hexagon bzw. Onion) des domänenzentrischen Architekturmuster abgebildet. Hierfür gibt es verschiedene Lösungsstrategien, die die architektonischen Elemente mehr oder weniger stark zum Ausdruck bringen.

Zur Förderung der Verständlichkeit wird bei Modulen ab mittlerer Größe und Komplexität eine ausdrucksstarke Variante, d.h. 11.1 und 11.2, empfohlen.

Risiko, wenn diese Entscheidung nicht aktiv getroffen wird

@ToDo

Entscheidungsalternativen

Architekturentscheidung #12: Wie wird die Abhängigkeit zwischen zwei Aggregates aufgelöst?

Vorbedingung

Keine

Entscheidungskontext

Im taktischen Domain-Driven Design wird eine Entkopplung auf Basis der Grenzen von Aggregates verfolgt. Aggregates haben einen unabhängigen Lebenszyklus.

Falls ein fachlicher Zusammenhang hergestellt werden muss, darf ein Aggregate ein anderes Aggregate nur über dessen Identität referenzieren. Die Referenz muss zur Laufzeit aufgelöst werden.

Abhängigkeiten dieser Art sind musterartig und gleichartig zu behandeln, um die Komplexität gering zu halten.

Welches Muster als Standard dienen kann und in welchen Szenarien auf alternative Lösungsstrategien zurückgegriffen wird, muss als kollaborative Architekturentscheidung im Team getroffen werden.

Risiko, wenn diese Entscheidung nicht aktiv getroffen wird

@ToDo

Entscheidungsalternativen

Das Bounded Context Game

Kartendeck

Ziel des Spiels

Das Ziel des Bounded Context Game ist es, Bounded Context-Kandidaten anhand bekannter Heuristiken zu identifizieren und zu beschreiben.

Heuristiken für Bounded Context Schnitte sind:

• Business Capabilities
• Sprach- und Modellunterschiede,
• Einseitiger Informationsfluss,
• Kohäsive Gruppierung von Aktivitäten (Prozesse, Workflows und Use Cases),
• Unterschiedliche Auslöser,
• Eigenständige Erzeugung von Ergebnissen,
• Teams und Lokation

Die Mission

Einen Bounded Context zu identifizieren und in einem Mindestumfang zu beschreiben, stellt eine Mission für das Team dar. Die Mission ist erfüllt, wenn der Bounded Context im Mindestumfang anhand des Bounded Context Canvas der DDD-Crew beschrieben ist.

Zum Mindestumfang gehört:

• Zweck, Verantwortlichkeiten, Existenzbegründung
• Angewendete Heuristiken für den Schnitt
• Wichtigste Geschäftsereignisse und Domänenobjekte

Das Spiel besteht aus mehreren Missionen und ist zu Ende, wenn alle Bounded Contexts einer Business-Domäne oder Subdomäne definiert sind.

Spielvorbereitung

Um das Bounded Context Game zu spielen, wird visualisiertes Wissen über die Business-Domäne benötigt.

Diese Spielgrundlage entsteht als Ergebnisse der Domain Discovery mittels Collaborative Modeling. Aus unserer Erfahrung passende Visualisierung von Domänenwissen finden sich in

• einer Business Capability Map,
• in einem Event Storm,
• in Domain Stories,
• Examples und Rules auf Basis von Example Mapping,
• Customer Journeys,
• fachlichen Prozessmodellen sowie
• einer Kombination aus den genannten Artefakten.

Metaphorisch oder auch physisch stellen diese Modelle das Spielfeld des Bounded Context Game dar.

Spielverlauf

1 Wissen teilen (30 bis 90 Minuten)

Die Moderator/in stellt die Artefakte der Domain Discovery vor und erläutert die Zusammenhänge und Herausforderungen der Business-Domäne. Die Spieler/innen haben die Möglichkeit, Fragen zu den fachlichen Anforderungen zu stellen.

2 Austausch und Analyse (30 bis 60 Minuten)

In der nächsten Spielphase setzt sich jede Spieler/in für sich oder im Austausch mit anderen Spieler/innen mit den fachlichen Artefakten auseinander und analysiert den Sachverhalt hinsichtlich der anzuwendenden Heuristiken.

3 Karten legen und Bounded Context definieren (30 bis 60 Minuten)

Mindestens eine Spieler/in beginnt nun ihren ersten Bounded Context Schnitt auf dem Spielfeld zu visualisieren (z.B. durch Einkreisung) und die Karten zu legen, die als Heuristik für den Schnitt angewendet werden.

Dadurch erhält die Diskussion einen Scope, und andere Spieler/innen werden eingeladen, ihre Karten ebenfalls zu legen und ihre Perspektive zu erläutern. An dieser Stelle ist die Moderator/in gefordert, die Gruppendiskussion zu lenken, sodass nach 30 bis 60 Minuten eine erste Beschreibung für einen Bounded Context entsteht.

In der Regel bringt diese Diskussion bereits Anhaltspunkte für weitere Bounded Context Kandidaten zum Vorschein, und der nächste Schritt kristallisiert sich durch diese Spieldynamik heraus. Ist dies nicht der Fall, beginnt wieder eine Spieler/in mit der visualisierung eines Schnitts und legen der Karten.

Das Spiel ist beendet, wenn alle auf dem Spielfeld dargestellten Fähigkeiten und Funktionen in einem Bounded Context verortet sind und jeder Bounded Context beschrieben ist.

Visueller Spielablauf

Das Context Mapping Game

Kartendeck

Ziel des Spiels

Das Context Mapping Game hat das Ziel, Abhängigkeiten zwischen Bounded Contexts unter Berücksichtigung des

• Call Flow,
• Model Flow sowie
• Influence Flow

zu gestalten.

Die Mission

Die Definition der Abhängigkeiten zwischen zwei Bounded Contexts anhand der Context Mapping Patterns von Domain-Driven Design stellt eine Mission des Teams dar. Das Spiel endet, sobald alle Missionen abgeschlossen sind. Dies bedeutet, dass alle Abhängigkeiten zwischen Bounded Contexts definiert wurden.

Spielvorbereitung

Die Vorbedingung für das Spielen des Context Mapping Game ist die Bekanntheit der Bounded Contexts. Jeder Bounded Context ist mittels Bounded Context Canvas beschrieben. Die befüllten Bounded Context Canvas werden physisch oder digital als Spielfeld verwendet. Sind Subdomänen bekannt, empfiehlt sich, Bounded Contexts der gleichen Subdomäne gruppiert auf dem Spielfeld darzustellen.

Spielverlauf

1. Dependency Storming (10 bis 20 Minuten)

Im ersten Schritt des Context Mapping Game entscheidet sich das Team für die erste Mission, d.h. für einen zu betrachtenden Bounded Context. Die Mission beginnt mit 10 Minuten Brainstorming von Abhängigkeiten für den Bounded Context (Dependency Storming). Eine Abhängigkeit wird als

• Command,
• Query,
• Event,
• (Sub-)System oder
• Akteur

zum Ausdruck gebracht.

Die Abhängigkeiten wird als ein- bzw. ausgehenden Abhängigkeiten kategorisiert und als Sticky Notes auf dem Spielfeld platziert.

2. Gruppierung der Abhängigkeiten (10 Minuten)

Die Gruppe steigt nun in eine erste Diskussion über die identifizierten Abhängigkeiten ein und gruppiert gleiche Nennungen sowie inhaltliche zusammengehörige Elemente (z.B. passendens Command oder Query zu einem System oder Akteur).

Identifizierte Abhängigkeiten zwischen Bounded Contexts können optional durch eine Verbindungslinie auf dem Spielfeld visualisiert werden.

3. Diskussion und Karten legen (15 Minuten)

Im nächsten Schritt wird jede Abhängigkeit im Team mit einer Timebox von 15 Minuten diskutiert. Hierbei hat jede Spieler/in die Möglichkeit, ihre Ansicht zu teilen, andere Ansichten aufzunehmen und in den Austausch über die dargestellten Sachverhalte zu gehen.

Anschließend legt jede Spieler/in seine Karte und teil somit seine Ansicht über die Beziehungsdefinition zwischen zwei Bounded Contexts. Eine Abhängigkeit definiert zu durch das Legen der Rollenkarte (Up- und Downstream) und der Musterkarte (Context Mapping Pattern je Rolle).

4. Entscheidungsfindung (15 Minuten)

Wenn sich eine gemeinsame Basis mit Ausreißern aufzeigt, kann die Entscheidungsfindung durch die Erklärung der Ausreißer gestartet werden. Wenn das Ergebnis sehr unterschiedlich oder einheitlich ist, beginnt eine beliebige Spieler/in mit der Schilderung ihrer Sicht.

Durch den Austausch im Team klären sich nicht mehr passende Muster und Rollen und in der Folge werden die Spielkarten vom Spielfeld entfernt. Die Abhängigkeit gilt als definiert, wenn die gelegten Karten eine valide und widerspruchsfreie Abbildung

• der Context Mapping Patterns mittels Musterkarten und
• Rollendefinition mittels Rollenkarten abbilden und
• alle Spieler/innen über diese Definition der Beziehungsdefinition übereinstimmen.

Visueller Spielablauf

Das Strategic Classification Game

Kartendeck

Ziel des Spiels

Das Strategic Classification Game zielt darauf ab, die strategische Klassifikation einer Subdomäne oder Bounded Context zu ermitteln und die zur Klassifikation passende Handlungsstrategie abzuleiten.

Die Mission

Ermittlung der strategischen Klassifikation und Handlungsstrategie anhand des Bewertungs- und des Handlungsstrategieschema. Das Spiel endet, sobald dies für alle Subdomänen bzw. Bounded Contexts einer Business-Domäne erfolgt ist.

Spielvorbereitung

Die Vorbedingung für das Spielen des Strategic Classification Game ist die Bekanntheit der Subdomänen und Bounded Contexts. Jeder Bounded Context ist mittels Bounded Context Canvas beschrieben. Die Bounded Contexts werden gruppiert anhand der Subdomäne dargestellt. Dies wird als Spielfeld (physisch oder digital) verwendet.

Spielverlauf

1. Subdomäne (Bounded Contexts) bewerten (60 Minuten)

Das Spiel beginnt mit der Auswahl dem ersten Bewertungsobjekt (Subdomäne oder Bounded Context). Dies entspricht der Auswahl der ersten Mission. Für dieses Bewertungsobjekt wird das dargestellte Bewertungsschema ausgefüllt.

In den ersten 15 Minuten erhalten die Spieler/innen die Möglichkeit sich Gedanken zu machen oder auch bilateral sich mit anderen Spieler/innen auszutauschen. Die Karten des Strategic Classification Game geben Hilfestellung und erklären die Bewertungskriterien und ihre Einstufung.

Nach dieser Einführungsphase startet die Gruppendiskussion, in der eine beliebige Spieler/in ihre Bewertung für das erste Bewertungskriterium mitteilt. Die Mitspieler/innen steigen in die Diskussion ein und legen ebenfalls ihre Karten auf das Spielfeld. Die Diskussion im Team führt zu einer Entscheidung hinsichtlich der Einstufung in gering, mittel oder hoch.

Der Vorgang wird für jedes Bewertungskriterium wiederholt.

2. Strategische Klassifizierung entscheiden (15 bis 30 Minuten)

Aufbauend auf der Bewertung der einzelnen Kriterien wird im nächsten Schritt die strategische Klassifikation anhand des Bewertungsschemas abgeleitet und im Core Domain Chart festgehalten.

3. Handlungsstrategie festlegen (15 bis 30 Minuten)

Im nächsten Schritt analysieren die Spieler/innen die zur strategischen Klassifizierung passende Handlungsstrategie. Diese besteht aus Realisierungsoptionen und Verantwortungsmuster. Auch hier sollen die Spieler/innen die Möglichkeit erhalten, dies eigenständig zu analysieren oder freiwillig den Austausch mit anderen Spieler/innen zu suchen.

Nach dieser Einführungsphase von 10 bis 15 Minuten legt erneut eine beliebige Spieler/in ihre Karte für die Realisierungsoption und für das Verantwortungsmuster auf das Spielfeld und begründet ihre Perspektive. Die anderen Spieler/innen folgen, und der Austausch in der Gruppe entsteht erneut. Abschließend muss in der Gruppe eine klare Entscheidung herbeigeführt werden. Diese wird festgehalten, durch Markierung im Handlungsstrategieschema.

Visueller Spielablauf

Das Tactical Architecture Game - Architecture Pattern

Coming soon...

Kartendeck

Ziel des Spiels

Die Mission

Spielvorbereitung

Miro Board

Spielverlauf

Spielfeld

Das Tactical Architecture Game - Starting Architecture Decisions

Kartendeck

Ziel des Spiels

Das Tactical Architecture Game - Starting Architecture Decisions hat das Ziel, grundlegende Architekturentscheidungen zu diskutieren und eine Teamentscheidung im Konsent für jede relevante Fragestellung zu finden. Hierfür stellt das Spiel ein Set an Entscheidungen, die Starting Architecture Decisions, eingeteilt in Entscheidungskategorien, bereit.

Die Mission

Jede Entscheidungskategorie stellt eine zu erfüllende Mission des Teams dar, die durch das Finden einer oder mehrerer Architekturentscheidungen abgeschlossen wird. Sind alle Missionen erfüllt, ist das Spiel zu Ende.

Spielvorbereitung

Zur Spielvorbereitung gehört die Vorbereitung des Spielfelds in physischer oder digitaler Form. Weiter benötigt jede Spieler:in ein Kartendeck.

Miro Board

Coming soon...

Spielverlauf

Das Spiel führt die Spieler:innen entlang der Entscheidungskategorien. Für jede Entscheidung startet ein Entscheidungsfindungsprozess zwischen den Spieler:innen. Die Abhängigkeit einer Entscheidung zu einer anderen sind ebenfalls durch den Spielverlauf berücksichtigt.

Die Entscheidungskategorien werden entsprechend der beschriebenen Reihenfolge für domänenzentrierte oder vertikal geschichtete Architekturmuster werden beschriebenen folgenden Reihenfolge durchlaufen:

Die Bestandteile des Entscheidungsfindungsprozesses einer taktischen Architekturentscheidung sind:

• Austausch über Fragestellung und Lösungsstrategie zur Förderung eines gemeinsamen Verständnisses
• Austausch über Fragestellung und Lösungsstrategie im spezifischen Projektkontext anhand bekannter Anwendungsfälle und Qualitätsanforderungen
• Formulierung von Entscheidungsalternativen
• Finden einer Konsententscheidung im Team

Jede Entscheidung muss innerhalb einer Timebox von 45 Minuten gefunden werden. Von dieser Timebox sind mindestens 15 Minuten für die Dokumentation der Architekturentscheidungen, insbesondere hinsichtlich verworfener Alternativen sowie Konsequenzen der Entscheidung.

Spielfeld