Domain-Driven Design ermöglichen

Wenn ein Geschäftsmodell oder ein Projektvorhaben von Grund auf neu entsteht, bietet das eine komfortable Ausgangslage für die Nutzung von Ansätzen wie DDD. Im Gegensatz dazu bringt ein Brownfield naturgemäß Altlasten und technische Schulden mit. Die Integration von DDD in eine solche Umgebung erhöht die Komplexität für die Beteiligten erheblich. Dennoch ist es oft unumgänglich, die Architektur in einem Brownfield zu modernisieren, da andernfalls die Weiterentwicklung und Innovation des Geschäftsmodells behindert werden können. Über lange Zeit gewachsene IT-Systeme und Abhängigkeitsstrukturen zwischen Entwicklungsteams machen die Architektur hier zu einem Engpass [1]. Tune und da Silva beschreiben das „Architecture Modernization Enabling Team“ [2] (AMET), inspiriert von der Idee des Enabler-Teams aus dem Ansatz Team Topologies [3], um eine Businessdomäne dabei zu unterstützen, sich mit der Philosophie von DDD neu zu erfinden und zu modernisieren.

Eine Grundlage für erfolgreiche Softwareentwicklung ist ein funktionierendes Team, das zielführend zusammenarbeitet und die vielfältigen Fähigkeiten der Teammitglieder für ein gemeinsames Ziel einsetzt. Die Voraussetzung dafür ist, dass im Team alle notwendigen Fähigkeiten vorliegen. Gleiches gilt für die Zusammenarbeit zwischen Teams, die als Verbund ein Softwareprodukt entwickeln. Es ist jedoch unrealistisch, davon auszugehen, dass in jedem Team und im übergreifenden Verbund alle benötigten Fähigkeiten in ausreichender Tiefe vorhanden sind. An dieser Stelle wird das Enabler-Team aktiv. Es konzentriert sich im Wesentlichen darauf, Wissenslücken in anderen Teams zu schließen und diese in einer Balance für andere Aufgaben und Anforderungen weiterzuentwickeln [3].

Weiterhin gibt es Stream-aligned Teams mit der Verantwortung, stets einen kontinuierlichen Fluss wertschöpfender Geschäftsfähigkeiten zu realisieren. Sie unterliegen hohem Zeitdruck und die Time-to-Market ist entscheidend für das Erreichen der Geschäftsziele. Ein Team mit dieser Aufgabe muss kontinuierlich am Ball bleiben und sich und die Software verbessern und voranbringen. Da diese Anforderungen im Widerspruch stehen, werden Stream-aligned Teams für einen Zeitraum und zweckgebunden von Enablern begleitet. Gleiches gilt für fachlich orientierte Platform-Teams, die wiederverwendbare Fähigkeiten für mehrere Stream-aligned Teams als Service anbieten [3].

Der Teamtyp Complicated-Subsystem-Team vervollständigt die Team-Topologie-Lehre. Im Hinblick auf das Enabling von DDD mittels Gamification durch ein AMET fokussieren wir uns auf die Idee des Enablings von Stream-aligned und Platform-Teams, die im Verbund komplexe Businesssoftware entwickeln.

Strategisches Domain-Driven Design

Die DDD-Crew beschreibt DDD als Architektur- und Entwicklungsansatz, der fachliches Denken und die fachliche Ausrichtung des Softwaresystems in jedem Schritt des Entwicklungsprozesses in den Vordergrund stellt. DDD besteht dabei aus den Säulen „Domain Discovery“, „Strategic Architecture“ und „Tactical Design“ (Abb. 1) [4].

Der Begriff Domäne ist in DDD allgegenwärtig, und es ist wichtig zu verstehen, was sich dahinter verbirgt. Eine Businessdomäne bezeichnet den Bereich, in dem ein Unternehmen aktiv ist, am Markt teilnimmt und Produkte oder Dienstleistungen für Kunden anbietet [5]. Die Perspektive auf die Businessdomäne wird in den Problem- und den Lösungsraum unterteilt. Der Problemraum beinhaltet die fachliche Problemstellung, die gelöst werden muss. Welche Geschäftsziele wurden definiert, welche Geschäftsfähigkeiten müssen dem Kunden am Markt angeboten werden, und welche unterstützenden Fähigkeiten werden benötigt?

Das führt zu einer ersten Grobstrukturierung der Businessdomäne, und deren Zerlegung in Subdomänen deutet sich an. Das sind Elemente der Erforschung der Businessdomäne (Domain Discovery) mit Übergang zur strategischen Architektur (Strategic Architecture) [6]. Bei der Erforschung der Businessdomäne kommen Methoden der kollaborativen Modellierung (Collaborative Modeling) zum Einsatz. Diese Phase kann sehr intensiv sein, ermöglicht jedoch, fachliches Wissen zu visualisieren und zu teilen. Sie bildet das Fundament für strategische und soziotechnische Architekturentscheidungen (Kasten: „Domain Dicovery mit Collaborative Modeling“).

Auf der strategischen Architekturebene formuliert DDD mehrere Designheuristiken für die Definition von Bounded Contexts als kleinstes strategisches Modularisierungsmittel. Durch Bounded Contexts wird die Dekomposition der Subdomänen in fachlich möglichst unabhängige Module durchgeführt. Während die Zerlegung der Businessdomäne in Subdomänen ein Mittel zur Komplexitätsreduktion im Problemraum darstellt, ist die Definition von Bounded Contexts ein Übergang in den Lösungsraum. Ein Bounded Context ist ein fachlich abgrenzbarer Bereich, der gleichzeitig eine physische Grenze zu anderen Bounded Contexts darstellt. Ein Bounded Context befindet sich im Eigentum eines Teams und wird unabhängig von anderen Bounded Contexts versioniert, weiterentwickelt und in Produktion gebracht. Der Bounded Context kann auf der technischen Architekturebene durch ein oder mehrere IT-Systeme (z. B. bei Microservices) realisiert werden [6].

Das Besondere an Domain-Driven Design und am Bounded Context ist, dass das Domänenmodell im Mittelpunkt steht. Durch dieses Modell werden Eigenschaften, Ereignisse und Funktionen der Businessdomäne zum Ausdruck gebracht. Als allgegenwärtige Sprache (Ubiquitous Language) dient das Domänenmodell als Bindeglied zwischen allen Projektphasen (Discover, Plan, Do, Check, Adjust), Architekturebenen (strategische, soziotechnische und taktische Architektur) sowie den beteiligten Personen (Architekt:in, Entwickler:in, Product Owner, Agile Coach, Tester:in, UX-Designer:in etc.).

Neben den bereits erwähnten Eigenschaften eines Bounded Contexts ist der entscheidende Punkt, dass der Bounded Context einen abgegrenzten Bereich (Bounded) um die Bedeutung eines fachlichen Modells (Context) darstellt. Domain-Driven Design formuliert das Prinzip, dass jeder Bounded Context sein eigenes Domänenmodell spezifisch und fachlich eindeutig realisieren sollte. Das Domänenmodell existiert folglich nur in diesem Bounded Context und hat dort Gültigkeit [6], [7]. Fowler [8] erklärt das anhand der Domänenobjekte „Kunde“ und „Produkt“ mit unterschiedlichen Perspektiven der Vertriebs- und Supporteinheiten auf diese Geschäftsobjekte. Fachliche Abhängigkeiten existieren in der Realität selbstverständlich trotzdem und müssen als Abhängigkeiten zwischen Bounded Contexts berücksichtigt werden. Das geschieht im Context Mapping unter Berücksichtigung der Domänenmodelle (Abb. 2).

Der Weg zum Bounded-Context-Schnitt

Business Capabilities (Geschäftsfähigkeiten) sind ein Konzept, das dazu dient, die verschiedenen Fähigkeiten oder Funktionen eines Unternehmens zu identifizieren und zu organisieren. Business Capabilities stellen die Was-Perspektive des Unternehmens oder einer Businessdomäne dar, die es ermöglicht, gesetzte Geschäftsziele zu erreichen. In einer Business Capability Map werden Business Capabilities in Cluster eingeteilt, um eine erste Strukturierung zu erhalten [9]. Ein Beispiel zeigt Abbildung 3 für die Businessdomäne Elektromobilität. Existiert eine Business Capability Map, ist sie eine gute Informationsquelle über die Businessdomäne. Ziel ist es, ein erstes Verständnis für die Herausforderung und Komplexität des Business aufzubauen und dieses Verständnis als Ausgangspunkt für die Modernisierung zu verwenden. Existiert keine Business Capability Map, hilft es, eine für die Grobstrukturierung der Businessdomäne zu erstellten. Denn die sinnvolle Gruppierung zusammengehöriger Business Capabilities (Kohäsion) ist eine Heuristik zum Schneiden von Bounded Contexts [6].

Die Betrachtung und Gruppierung der Was-Perspektive reicht allerdings für nachhaltige strategische Architekturentscheidungen nicht aus. Dafür muss auch die Wie-Perspektive der Businessdomäne betrachtet werden. Im Problemraum beschreibt sich die Wie-Perspektive durch fachliche Szenarien, Anwendungsfälle oder durch einen Strom von Geschäftsereignissen. Das sind Ergebnisse aus Workshops der kollaborativen Modellierung, wie z. B. Domain Storytelling und Event Storming.

Abbildung 4 zeigt den Strom von Geschäftsereignissen für die Businessdomäne E-Mobilität. Anhand von Domain Events (Geschäftsereignissen) werden die Fachsprache und die Domänenobjekte sichtbar. Die Diskussion unter den Workshopteilnehmern ergibt, ob es ein unterschiedliches oder gemeinsames Verständnis hinsichtlich der Bedeutung eines Domänenobjekts in einem bestimmten fachlichen Kontext gibt. Das Ziel ist, zu einem gemeinsamen Verständnis zu kommen, indem klar wird, dass das Bild der Personen übereinstimmt oder ein spezifisches Verständnis in der Architektur ausgeprägt werden sollte. So zum Beispiel bei den Fachbegriffen „Wartung“ und „Reparatur“. Was ähnlich bis gleich wirkt und generisch implementiert werden könnte, hat unterschiedliche Auslöser, wie „Schadensmeldung erstellt“ oder „Wartungsintervall erreicht“ (Abb. 4) sowie unterschiedliche fachliche Zielsetzungen, wie die Wiederherstellung der Leistungsfähigkeit bei einer Reparatur im Gegensatz zum Erhalt der Leistungsfähigkeit bei einer Wartung.

Dieses Verständnis kann mittels Collaborative Modelling herausgearbeitet und festgehalten werden. Darauf aufbauend sind die Heuristiken „Sprach- und Modellunterschiede“ sowie „Unterschiedliche Auslöser“ für Bounded-Context-Schnitte anwendbar. Das ist wichtig, denn mehrdeutige Domänenobjekte führen dazu, dass auf diese Objekte unterschiedliche Anwendungsfälle wirken, die potenziell von unterschiedlichen Auftraggebern verantwortet werden. Die Folge ist Komplexität durch Ausnahmefälle, Randbedingungen und kontextspezifische Regeln. Dieser Sachverhalt wird auch als Antipattern „Mehrdeutiges Modell“ bezeichnet und es ist empfehlenswert, je Bounded Context spezifische Modelle abzubilden, die nur in diesem Kontext ihre Gültigkeit haben. Auf technischer Architekturebene kann Kopplung reduziert werden, indem Abhängigkeiten über Schnittstellen anstatt über geteilte Modelle realisiert werden [5]-[7].

Abbildung 5 zeigt die Domain Story für das fachliche Szenario „Ladevorgang durchführen und abrechnen“. Dargestellt sind die Akteure „Kund:in“ und das IT-System „extremCharge“. Die Akteure führen Aktivitäten, dargestellt als Pfeile, auf oder mit Arbeitsgegenständen aus. Beide Akteure teilen sich überwiegend den Arbeitsgegenstand „Ladevorgang“. Das Szenario zeigt insbesondere, wie der Arbeitsgegenstand „Ladevorgang“ über Aktivitäten mit anderen Arbeitsgegenständen in Beziehung steht, wie z. B. der Rechnung in Schritt 8. Hier wird eine differenzierte Perspektive auf den Ladevorgang im Vergleich zu den vorherigen Schritten deutlich. An dieser Stelle ist die Heuristik „Sprach- und Modellunterschiede“ anwendbar. Weiter sind hier unterschiedliche „Prozesse, Workflows und Use Cases“ zu erkennen, bei denen Akteure ein „eigenständig erzeugtes Ergebnis“ erzielen. Auf das vorliegende Szenario lassen sich diese Heuristiken, wie in Tabelle 1 beschrieben, anwenden.

Die Heuristik „Einseitiger Informationsfluss“, wie z. B. in Abbildung 5 zwischen Schritt 6 und 7 dargestellt, ist ein weiterer Faktor für die Entscheidung, ob diese Schritte potenziell in unterschiedlichen oder im gleichen Bounded Context verortet werden. Abbildung 6 zeigt die Domain Story für das ebenfalls grobgranulare fachliche Szenario „Ladetarif erstellen und Ladevertrag abschließen“. Hier führen die Akteure Produktmanager:in und Kund:in unterschiedliche Aktivitäten auf das Objekt „Ladetarif“ aus. Auch hier ist ein einseitiger Informationsfluss zwischen den beiden Bereichen für die Erstellung des Ladetarifs und den Abschluss eines Ladevertrages sichtbar. Hofer und Schwentner [5] beschreiben einen einseitigen Informationsfluss als Anzeichen für unterschiedliche Bounded Contexts. Das verfeinert die Heuristik „Prozesse, Workflows und Use Cases“.

Abbildung 6 zeigt zudem je Akteur zusammengehörige Aktivitäten, die eine Beziehung zum Ladetarif aufweisen. Die „kohäsive Gruppierung zusammengehöriger Aktivitäten“ anstatt von Objekten und eine „signifikant unterschiedliche Verwendung“ eines Arbeitsgegenstands durch unterschiedliche Akteure sind ebenfalls Indikatoren für eigene Bounded Contexts [5]. Im skizzierten Beispiel spricht die Anwendung der Heuristiken für eine Aufteilung dieser Aktivitäten auf unterschiedliche Bounded Contexts, die jeweils ihre Sicht auf das Domänenobjekt „Ladetarif“ realisieren.

Eine weitere Heuristik „Teams und Lokation“ adressiert eine organisatorische Dimension, die später im Context Mapping (siehe Teil 2 dieser Artikelserie) verfeinert wird. Umso weiter Teams in ihrer Zusammenarbeit und Lokation voneinander entfernt sind, desto unterschiedlicher kann sich das fachliche Verständnis ausprägen, und im schlimmsten Fall entsteht ein unverhältnismäßiger Aufwand für Kommunikation und Koordination. Das gilt sowohl für Fach- als auch für Produktentwicklungs- sowie Softwareentwicklungsteams [6].

Abbildung 7 zeigt einen möglichen Bounded-Context-Schnitt, abgeleitet auf Basis der beschriebenen Heuristiken. Domain-Driven Design Cards mit dem Bounded Context Game haben das Ziel, die Heuristiken gemeinsam in einem kollaborativen Analyse- und Entscheidungsfindungsprozess anzuwenden.

Gamification

Die Kernidee von Gamification besteht darin, Prinzipien und Elemente aus Spielen in andere Kontexte zu integrieren, um Motivation, Kreativität, Engagement und Interaktion von Menschen 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 [10], [11]. Mit Fokus auf Domain-Driven Design Cards werden Spieler:innen als Team mit Herausforderungen konfrontiert, die sie gemeinsam meistern müssen. Das geschieht in Form von Missionen, die im Spielverlauf abgeschlossen werden müssen. Gamification-Ansätze wie Domain-Driven Design Cards erfreuen sich in verschiedenen Bereichen der Organisations- und Softwareentwicklung großer Beliebtheit. So haben Domain-Driven Design Cards Inspiration bei Backlog Refinement Cards [12], unFix Cards [13] oder Cards 42 [14] gefunden.

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. Das 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. Bei einer Modernisierung mit Hilfe eines AMET werden diese Rollen von diesem abgedeckt.

Die Spiele Bounded Context Game, Strategic Classification Game, Context Mapping Game und Architecture Game von Domain-Driven Design Cards bieten Raum für Kommunikation, Wissensaustausch und -aufbau sowie für die gemeinschaftliche Gestaltung der Architektur mittels DDD auf strategischer, soziotechnischer und taktischer Architekturebene.

Spielanleitung für das Bounded Context Game

Im Folgenden widmen wir uns den Regeln und dem Ablauf des Bounded Context Game.

Ziel des Spiels

Das Ziel des Bounded Context Game ist es, Bounded-Context-Kandidaten anhand der folgenden Heuristiken zu identifizieren und zu definieren:

• Business Capabilities

• Sprach- und Modellunterschiede

• einseitiger Informationsfluss

• kohäsive Gruppierung von Aktivitäten

• unterschiedliche Auslöser

• Prozesse, Workflows und Use Cases

• Teams und Lokation

Das stellt die Mission des Teams dar. Die Mission ist erfüllt, wenn Einigkeit hinsichtlich der vollständigen Verortung aller gewünschten Fähigkeiten auf Bounded Contexts hergestellt ist und alle Bounded Contexts definiert sind. Der Mindestumfang umfasst den Zweck, die Verantwortlichkeiten und die Existenzbegründung des Bounded Context sowie die zugrunde liegenden Heuristiken für den Schnitt. Des Weiteren gehört ein gemeinsames Verständnis der wichtigsten Geschäftsereignisse und Domänenobjekte sowie deren spezifische Bedeutung im Bounded Context dazu.

Eine empfehlenswerte Vorlage für die Beschreibung eines Bounded Context mit dem beschriebenen Mindestumfang ist der Bounded Context Canvas der DDD-Crew, der weiterführend iterativ mit zusätzlichen Informationen vervollständigt werden kann (Abb. 8). Ein Canvas ist ein visuelles Werkzeug, um komplexe Konzepte oder Probleme auf übersichtliche und strukturierte Weise darzustellen. Er bietet in der Regel klare Strukturen, die den Beteiligten dabei helfen, Informationen zu organisieren, Ideen zu generieren und Entscheidungen zu treffen. Der Bounded Context Canvas ist ein Instrument, um kollaborativ einen Bounded Context zu definieren und die wichtigsten fachlichen Architekturentscheidungen zu dokumentieren [15].

Spielvorbereitung

Die Vorbedingung für das Spielen des Bounded Context Game ist die Wissensgrundlage für die Mission. Diese Wissensgrundlage findet sich in dieser Artikelserie in der Business Capability Map, im Event Storming und in Domain Stories. Metaphorisch (oder auch physisch) stellt diese Wissensgrundlage das Spielfeld des Bounded Context Game dar (Abb. 9). Auch Beschreibungen auf Basis anderer Methoden, wie z. B. Example Mapping sind möglich. Unabhängig davon ist zu empfehlen, dass Teilnehmer:innen des Bounded Context Game auch bei den Workshops dabei waren, bei denen diese Artefakte angefertigt wurden. Eine Voraussetzung für das Bounded Context Game ist das jedoch nicht, solange ausreichend Teilnehmer:innen dabei sind, die diesbezügliches Wissen und Informationen teilen können.

Spielverlauf

Sind nicht alle Spieler:innen mit den Herausforderungen, Szenarien und Anwendungsfällen, die auf dem Spielfeld dargestellt sind, vertraut, beginnt das Spiel mit einer Darstellung und Erklärung durch die vorhandenen Wissensträger:innen. Abhängig vom Umfang kann das zwischen 30 und 90 Minuten in Anspruch nehmen. Das ist die Spielphase „Wissen teilen“. Die einzelnen Spielphasen sind in Abbildung 10 dargestellt.

In der nächsten Spielphase setzt sich jede Spieler:in für sich oder im Austausch mit anderen Spieler:innen in Kleingruppen mit den fachlichen Artefakten auseinander und analysiert den Sachverhalt hinsichtlich der anzuwendenden Heuristiken. Diese Spielphase namens „Austausch und Analyse“ hat eine vereinbarte Timebox zwischen 30 und 60 Minuten, in der keine Karten auf das Spielfeld gelegt werden. Die Gedanken und Schlussfolgerungen der Spieler:innen sollen sich in dieser Phase – mit Ausnahme eines freiwilligen Austausches in Kleingruppen – unvoreingenommen entwickeln können.

Nach Ablauf der Timebox beginnt die erste Spieler:in, ihre Karten zu legen und ihre Perspektive anhand der gelegten Heuristiken zu begründen. 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 die Spieldynamik heraus. Ist das nicht der Fall, beginnt wieder eine Spieler:in den Austausch im Team und das Finden des Scopes für den nächsten Schritt, indem sie ihre Karten legt.

Das Spiel ist beendet, wenn für jeden Bereich auf dem Spielfeld Karten gelegt wurden und auf Basis der Teamarbeit Bounded-Context-Schnitte als weitere Arbeitsgrundlage beschrieben sind. Durchaus herausfordernd für die Moderator:in in einer größeren Gruppe ist die Herbeiführung von Entscheidungen, die die Problemstellung adäquat adressieren und ein Commitment im Team erreichen. Ist es schwierig, ein Commitment zu erzielen, empfiehlt sich der Einsatz von Methoden für die Entscheidungsfindung, wie z. B. Dot Voting oder Thumb Voting. Für Thumb Voting kann das Bounded Context Game mit unFix Decision Patterns [13] ergänzt werden. Dot Voting ist sowohl vor Ort mit Stift oder Klebepunkten als auch remote auf einem Collaboration Board einfach durchführbar.

Abbildung 11 und 12 visualisieren beispielhaft das bespielte Feld des Bounded Context Game zur Verdeutlichung des beschriebenen Spielablaufs. Dargestellt sind die Artefakte der Domain Discovery und die gelegten Spielkarten, um die Treiber für den Bounded-Context-Schnitt festzuhalten.

Karten

Abbildung 13 zeigt die Domain-Driven Design Cards des Bounded Context Game in der Übersicht. Neben dem Namen der Heuristik sind die wichtigsten Informationen dazu aufgeführt. Das Kartenset beinhaltet neben den beschriebenen Heuristiken ergänzende Prinzipien, die den Austausch im Team fördern. Das unterstützt den Aufbau von Verständnis sowie die gedankliche Auseinandersetzung und Anwendung der Heuristiken und Prinzipien in der eigenen Businessdomäne. Die Karten sind zum kostenlosen Download unter [16] verfügbar.

Fazit und Ausblick

Bounded Contexts sind vermutlich das bekannteste und eins der elementarsten Elemente von DDD. Ein Bounded Context ist mehr als ein Systemschnitt. Der starke Fokus auf die Fachlichkeit sowie die heuristische Herleitung des Bounded Context ist tiefergehend und systematischer als gängige Ansätze zur Herleitung von Systemschnitten. In der Einleitung zu DDD wurde bereits die Ganzheitlichkeit dieser Philosophie betont. Die Grundlage, das notwendige Wissen über die Domäne, bringt die Domain Discovery zum Vorschein. Auf dieser Basis erfolgt die Ableitung von Bounded Contexts und ein Bild der strategischen Architektur entsteht.

Die Betrachtung der strategischen Architektur wird im nächsten Schritt um soziotechnische Faktoren erweitert. Mittels der Methode Context Mapping wird die soziotechnische Architektur der Businessdomäne erarbeitet und beschrieben. Unterstützt wird das in ähnlicher Weise mit dem Context Mapping Game. Dieser Methode widmen wir den zweiten Teil dieser Artikelserie und vervollständigen die strategische Architekturebene.