Dependencies are eating the business domain
Abhängigkeiten spielerisch analysieren
Dependencies are eating the business domain
Abhängigkeiten spielerisch analysieren
Mit Domain-Driven Design Cards und dem Context Mapping Game stellen wir einen Gamification-Ansatz vor, um komplexe Beziehungsstrukturen zu analysieren und zu visualisieren.
Vor über einem Jahrzehnt prägte Marc Andreessen mit seinem Statement „Software is eating the world“ die Digitalisierungsbewegung von Unternehmen [1]. Inzwischen haben zahlreiche Geschäftsfelder tiefgreifende Veränderungen erfahren und neue Geschäftsmodelle sind entstanden. Diese sind auf Organisationsstrukturen und IT-Systemarchitekturen angewiesen. Wenn das Geschäftsmodell wächst, müssen auch diese Strukturen mitwachsen und sich neu ausrichten. Wächst das Geschäftsmodell zu schnell, können organisatorische und technische Strukturen oft nur schwer Schritt halten. Das führt zu einem undurchsichtigen und unpassenden Geflecht aus kommunikativen, koordinativen, technischen und fachlichen Abhängigkeiten. Dieses Schicksal, das wir in Anlehnung an Marc Andreessen als „Dependencies are eating the business domain“ bezeichnen, führt dazu, dass die Businessdomäne nur noch langsam oder gar nicht mehr wachsen und sich verändern kann. Unser Lösungsvorschlag: ein Gamification-Ansatz mit Domain-Driven Design Cards und dem Context Mapping Game.
Strategisches Domain-Driven Design
Der strategische Teil des Domain-Driven Designs beinhaltet die Dekomposition der Businessdomäne in Subdomänen und Bounded Contexts. Mit Hilfe einer Context Map werden die Abhängigkeiten zwischen den Bounded Contexts visualisiert. Dabei werden die Abhängigkeiten mittels Context-Mapping-Patterns beschrieben. Letztere stellen eine Mustersprache dar, um Abhängigkeiten auf technischer, fachlicher und organisatorischer Ebene zu gestalten. Auf diese Weise wird eine soziotechnische Architektur der Businessdomäne definiert, die nicht nur den fachlichen Systemschnitt, sondern auch die Entwicklungsteams hinter den Bounded Contexts berücksichtigt [2].
Das Ziel des Domain-Driven Architect besteht darin, Bounded Context auf der strategischen Architekturebene sinnvoll und in den meisten Fällen möglichst unabhängig von anderen Bounded Contexts zu gestalten. Eine optimale Lösung ist nicht immer möglich. Die Transparenz hinsichtlich der Abhängigkeiten sowie deren methodische Betrachtung sind jedoch sehr nützlich. Es geht darum, die Vor- und Nachteile sorgfältig abzuwägen und bewusste Entscheidungen zu treffen. Die bewusste Gestaltung von Abhängigkeiten ist dabei nicht nur zu Beginn eines Projekts wichtig. Zu diesem Zeitpunkt ist oft das Wissen unvollständig und Weiterentwicklungen sind nicht vorhersehbar. Daher ist eine regelmäßige Überprüfung und Anpassung sinnvoll. In der Praxis wird dies aber selten durchgeführt.
Eine Untersuchung der Abhängigkeiten ist besonders dann relevant, wenn das System oder das Projekt aus dem Gleichgewicht gerät. Dies geschieht in der Regel aufgrund verschiedener Arten von Wachstum. Zwei Szenarien, die Anlass geben, die Abhängigkeiten in der strategischen Architektur neu zu überdenken, sind das Wachstum des Systems und das Wachstum des Geschäftsmodells [3] (Kasten: „Wachstum und Folgen“).
Wachstum und Folgen
Wachstum des Systems
Das System wächst rasant und die Abhängigkeiten zwischen den internen Komponenten des Systems bauen sich stetig weiter auf. Zusätzlich werden immer mehr externe Systeme angebunden. Die Komplexität der Integration verknüpft sich mit der Herausforderung, unterschiedliche Domänen- und Kommunikationsmodelle zu handhaben. Wenn sich diese Modelle ändern, führt das zu Seiteneffekten und erfordert Anpassungen im System. Das System ist aufgrund der entstandenen Komplexität nur schwer erweiterbar.
Wachstum des Geschäftsmodells
Geschäftsmodelle und Organisationen wachsen, was über die Zeit Anpassungen in der IT-Architektur bedingt. Das ist besonders dann der Fall, wenn das Geschäftsmodell auf einem monolithischen System gewachsen ist. Die Skalierung von Teams bedeutet nun eine Zerlegung des Systems in Subsysteme zur Aufteilung auf mehrere Teams. Dadurch entstehen neue Abhängigkeiten und bereits bekannte Abhängigkeiten zu externen Systemen müssen neu gedacht werden.
Businessdomäne, Bounded Context und Domänenmodell
Eine Businessdomäne ist der Bereich, in dem ein Unternehmen aktiv ist, am Markt teilnimmt und Kunden Produkte oder Dienstleistungen anbietet. Bounded Contexts sind das Mittel zur Zerlegung dieser Domäne in fachlich unabhängige Module der strategischen Architekturebene (Abb. 1). Ein Bounded Context ist ein fachlich abgrenzbarer Bereich, der gleichzeitig eine physische Grenze zu anderen Bounded Contexts darstellt. Er liegt in der Verantwortlichkeit eines Teams und wird unabhängig von anderen Bounded Contexts versioniert, weiterentwickelt und in Produktion gebracht.
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 erwähnten Eigenschaften eines Bounded Context ist der entscheidende Punkt, dass er einen abgegrenzten Bereich (Bounded) um die Bedeutung eines fachlichen Modells (Context) darstellt. DDD formuliert die Heuristik, dass jeder Bounded Context sein eigenes Domänenmodell spezifisch und fachlich eindeutig realisieren sollte. Das Domänenmodell existiert folglich nur in diesem Bounded...