Prinzipien für die Umsetzung querschnittlicher Bounded Contexts

Wir greifen in diesem Artikel das fiktive Beispiel einer Film- und Musikplattform „Spotiflix“ aus dem vorhergehenden Blogartikel „Kriterien für die Einführung von querschnittliche Bounded Contexts“ auf.
Für das Verständnis dieses Beitrags genügt es jedoch zu wissen, dass Spotiflix aus dem Zusammenschluss eines Film- und eines Musikanbieters hervorgegangen ist. Auf dieser Plattform können Nutzer:innen Filme und Musik kaufen und abspielen. Die Funktionalität, solche Medien in einen Warenkorb zu legen und die Produkte zu kaufen, soll als querschnittliche Fachlichkeit zentral angeboten werden. Nach dem Zusammenschluss brachten Filme und Musik zunächst jeweils ihren eigenen Warenkorb mit, welche das Entwicklungsteam über eine UI-Integration aus Nutzer:innensicht vereinheitlichte. Die geplante Architektur von Spotiflix ist in Abbildung 1 zu sehen.

Datenhaltung, Schnittstellen und Entwicklung

Der Warenkorb bildet einen eigenen Bounded Context, und damit eine modelltechnische Grenze, der Subdomänen wie Produktkataloge für Filme und Musik, die Bestellübersicht oder den Bezahlvorgang beinhaltet. Wie die Bounded Contexts „Musik-Streaming“ und „Film-Streaming“, kennt dieser Begriffe wie „Film“ oder „Song“. Die konkrete Bedeutung und Modellierung dieser Begriffe unterscheidet sich jedoch von Bounded Context zu Bounded Context. Die Grenzen der Bounded Contexts sind auch die Grenzen der Ubiquituous Language.

Wenn aber beide Bounded Contexts „Film-Streaming“ und „Warenkorb“ den Begriff oder die Entität „Film“ kennen, auch wenn die Modelle dazu unterschiedlich aussehen, stellt sich direkt die Frage, welcher Bounded Context die Hoheit oder Ownership über die „Filme“ besitzt.
Hier gibt es sehr viele Möglichkeiten:
Liegen die Filme beim Film-Streaming und der Warenkorb muss nach den vorhandenen Filmen fragen? Falls ja, was ist mit Attributen, die nur im Warenkorb eine Rolle spielen? So ist ein Film vielleicht noch nicht zu streamen, aber bereits vorbestellbar. Oder ein Film ist nur noch für Nutzer:innen zu streamen, die den Film bereits gekauft hatten; ein weiterer Verkauf ist aber etwa aus rechtlichen Gründen nicht mehr möglich.

Ist es umgekehrt? In diesem Falle müsste der Film-Player die Daten zum Streamen aus dem Warenkorb erhalten. Das klingt seltsam – eine Idee der Zentralisierung des Warenkorbs war schließlich, unterschiedliche Qualitätsziele für das Verkaufen und das Streamen von Filmen besser zu erreichen. Wenn wir die Filme zum Streamen aus dem Warenkorb beziehen, muss dieser doch wieder Qualitätsziele wie Performanz erfüllen, um kein Flaschenhals für das Film-Streaming zu werden.

Werden die Filme zentral gelagert und Warenkorb wie Film-Streaming bedienen sich aus derselben Datenquelle? Welches Team hat dann die Verantwortung über Persistenztechnologie und Datenformat?

Führen beide Bounded Contexts jeweils einen eigenen Datenbestand von Filmen? Wie sorgen wir in diesem Falle dafür, dass die Daten zusammenpassen? Denn schließlich wäre es sehr ärgerlich für die Nutzer:innen, wenn ein eben gekaufter Film dann gar nicht abrufbar wäre, weil der gekaufte Film im Warenkorb und der abspielbare Film im Streaming nicht richtig verknüpft sind. Sämtliche Fragen stellen sich analog für das Medium Musik.

Und weiter ergeben sich viele Fragen für die Weiterentwicklung der verschiedenen Teile, die Pflege von Daten und Schnittstellen: Wie gehen wir mit Abhängigkeiten in Anforderungen um? Wer pflegt Daten ein? Wer definiert Schnittstellen und wie stellt das Team deren Funktionalität und entsprechende Anpassungen, auch qualitativ, über die Zeit hinweg sicher? Wie treffen wir übergreifende Architekturentscheidungen und wie kommunizieren wir sie?

Eine Frage der Abhängigkeiten

Wir stellen schnell fest, dass all diese Fragen und Problematiken in gewisser Weise mit Abhängigkeiten zu tun haben. Es geht stets um den Einfluss, den Entscheidungen und Änderungen in unserem querschnittlichen Bounded Context „Warenkorb“ auf andere Bounded Contexts – oder umgekehrt – haben. Die Frage, welche Herausforderungen ihr meistern müsst, um querschnittliche Fachlichkeit effektiv und effizient zentral bereitzustellen, lässt sich darauf reduzieren, welche Ausprägungen von Abhängigkeiten es gibt und wie ihr sie reduziert.

Gewisse Abhängigkeiten beeinflussen auch andere Abhängigkeiten. So hat etwa die Entscheidung über Datenhoheit oder Persistenztechnologie Einfluss auf Form und Qualitätsanforderungen von Schnittstellen. Zur Veranschaulichung dieser Abhängigkeiten zwischen verschiedenen Bounded Contexts führen wir ein einfaches Modell ein, welches in Abbildung 3 dargestellt wird.

Wir gehen von drei großen Abhängigkeitsbereichen zwischen Bounded Contexts aus:

• Datenhaltung: Wer welche Daten in welchem Format und mit welcher Technologie hält, beeinflusst damit andere Bounded Contexts, wenn diese die Daten oder Teile davon benötigen. Bei direktem Zugriff auf die Daten können Strukturänderungen zu fachlichen Fehlern, Technologieentscheidungen zu verfehlten Qualitätszielen führen.
  Der Film-Streaming Context interessiert sich vielleicht nicht vorrangig für die Länge eines Filmes, diese Information kann aus dem geladenen Film gezogen werden. Der Warenkorb hingegen möchte diese Information schnell abrufen und im Produktkatalog darstellen, ohne den Film selbst zu laden. Umgekehrt spielen die effiziente Speicherung und die Ladegeschwindigkeit von Filmen keine Rolle für den Warenkorb.
  Erfolgt der Zugriff über Schnittstellen, so ergibt sich die Abhängigkeit durch die erforderlichen (Qualitäts-)Anforderungen oder die Notwendigkeit der Datensynchronisation (siehe unten).
• Schnittstellen: Die Form, also Ein- und Ausgabeformate oder die Fehlerbehandlung, sowie die Qualität, etwa Verfügbarkeit und Performanz, von Schnittstellen hat per Definition Einfluss auf andere Bounded Contexts, denn diese werden genau für die Kommunikation mit anderen entworfen.
  Neben Form und Qualität spielt aber auch der Kopplungsgrad, den eine Schnittstelle realisiert, eine Rolle. Dieser ist zudem mehrdimensional, da er sich aus quantitativen und qualitativen Effekten zusammensetzt. Sowohl Aufrufhäufigkeit als auch die Stärke der Abhängigkeit zu einer Schnittstelle bestimmen den Grad der Kopplung. Muss der Warenkorb eine Liste von Filmen beim Film-Streaming abrufen und später, für genauere Informationen über einen einzelnen Film wieder dort anfragen, so schießen die Aufrufe schnell in die Höhe.
  Die Stärke der Abhängigkeit lässt sich etwa durch die Beantwortung von Fragen wie „Wie aktuell müssen die Daten sein?“ oder „Wie viel Funktionalität kann ich ohne diese Schnittstelle noch bereitstellen?“ einschätzen.
  Hält also etwa der Warenkorb ebenfalls gewisse Informationen über verfügbare Filme vor, so reduziert ihr nicht nur die Aufrufzahlen zwischen Warenkorb und Film-Streaming, sondern ihr könnt ggf. auch damit leben, dass die Daten im Warenkorb nicht jederzeit konsistent mit den Daten im Film-Streaming sind. So wäre etwa das Fehlen eines Filmes im Produktkatalog kurzzeitig zu verkraften und die Stärke der Abhängigkeit zum Film-Streaming sinkt. Die Definition von „kurzzeitig“ könnt ihr in einem Qualitätsszenario erfassen und diese Abhängigkeit damit sogar quantifizieren.
• Entwicklung: Die Weiterentwicklung eines Bounded Contexts kann Einfluss auf andere Bounded Contexts haben. Verschiedene Features lassen sich ggf. nicht ohne entsprechende Änderungen an anderer Stelle umsetzen. Die Anforderung, Hörproben oder Ausschnitte des Films im Produktkatalog des Warenkorbs als Kostprobe bereitzustellen, benötigt, wenn der Warenkorb die Daten nicht selbst hält, die Mitarbeit von Musik- und Film-Streaming. Entweder werden die entsprechenden Ausschnitte von Musik und Filmen an den Warenkorb geliefert und dieser muss nun doch auch das Abspielen von Medien in einem gewissen Rahmen beherrschen. Oder Film- und Musik-Streaming bieten eine Möglichkeit, den jeweiligen Player im Produktkatalog einzubinden und einen Ausschnitt des gewünschten Artikels abzuspielen.
  Unbedachte oder schlecht geschnittene Anforderungen können diesen Effekt verstärken oder die Freiheit mancher Teams und Produkte einschränken. Dies tritt besonders dann auf, wenn Anforderungen an den querschnittlichen Context nur aus der Sicht eines Konsumenten gedacht werden. Ein Beispiel hierfür folgt später.
  Unterschiedliche Arbeitsmodi und -setups beeinflussen die Art der Kommunikation zwischen verantwortlichen Teams und können damit die Abhängigkeiten unter Umständen sogar schwieriger handhabbar machen, indem „soziale“ Komponenten technische und fachliche Abhängigkeiten verkomplizieren.
  Zuletzt haben Architekturentscheidungen für querschnittlich genutzte Module und Services ggf. weitreichende Auswirkungen auf andere Bounded Contexts und müssen daher sinnvoll und im Sinne der Konsumenten als Gesamtheit getroffen, kommuniziert und dokumentiert werden, wie wir gleich sehen werden.

Wie bereits erwähnt beeinflussen sich die verschiedenen Abhängigkeitsbereiche ebenfalls, was Abbildung 3 durch Überschneidungen der Bereiche darstellt. Mögliche Einflussfaktoren zwischen diesen Bereichen sind:

• Synchronisation: Informationen über eine einzigartige, aber doppelt modellierte und gehaltene Ressource müsst ihr synchronisieren. Trennen wir etwa Produktkatalog im Warenkorb von den Filmen, welche vom Film-Streaming abgespielt werden können, so muss der Kauf eines Films im Warenkorb dazu führen, dass das Gegenstück im Streaming für den Nutzer oder die Nutzerin zur Verfügung steht. Kurz: Eine Information über die einzigartige, aber doppelt gehaltene und modellierte Ressource „Film“ muss synchronisiert werden.
  Hinterlegen wir hingegen Daten einzig und allein in einem Bounded Context, so benötigt es Schnittstellen, damit andere Bounded Contexts darauf zugreifen können. Erlauben wir stattdessen einen direkten Datenzugriff, so koppeln wir die Bounded Contexts direkt über die Persistenz, siehe oben. In der Regel beeinflusst die Datenhaltung jedoch die Schnittstellen.
• Sprache: Eine Abhängigkeit zwischen Bounded Contexts (in der Regel über Schnittstellen) beeinflusst unsere Zusammenarbeit. Formate und Qualitäten von Schnittstellen müssen ausgehandelt und entsprechende Lösungen gefunden werden. Dabei müssen wir damit umgehen, dass unterschiedliche Sprachen im Gebrauch sind, weshalb wir bei der Zusammenarbeit Dinge erklären und übersetzen müssen. Damit hat die Sprache in der Regel wieder Auswirkungen auf die Form und Semantik von Schnittstellen.
• Datenpflege: Die Entscheidung, Daten nur in Bounded Context A zu halten führt dazu, dass wir uns Gedanken darüber machen müssen, wie für Bounded Context B relevante Informationen gepflegt werden können. Umgekehrt würde eine Entscheidung, mehreren Teams vollen Zugriff auf gewisse Daten zu geben, uns zwingen, gemeinsam Technologieentscheidungen zu treffen und uns auf die Form und Regeln für die Pflege der Daten zu einigen.

Das vorgestellte Modell unterstützt Euch wirksam dabei, die für Eurer Projekt relevanten Abhängigkeitsfaktoren zu finden. Beginnt mit dem Abhängigkeitsbereich, der euch am wichtigsten für euer Problem erscheint. Schnell werdet ihr Konsequenzen für andere Bereiche diskutieren und viele Iterationen durchspielen. Es ist allerdings hilfreich, mit einem Abhängigkeitsbereich zu beginnen und nicht sofort die Überschneidungen zu anderen Bereichen zu untersuchen. Gewinnt zunächst für einzelne Facetten ein gewisses Verständnis. Wenn ihr bei der Anwendung weitere Facetten identifiziert, bin ich sehr am Austausch interessiert.

Besondere Risiken für querschnittliche Fachlichkeit

Diese Abhängigkeiten spielen immer eine Rolle, wenn verschiedene Teams unterschiedliche und nicht unabhängige Teile einer Software liefern.
Doch insbesondere bei der Bereitstellung von querschnittlicher Fachlichkeit können diese besonders schwerwiegend und einflussreich sein: Querschnittliche Fachlichkeit wird in der Regel von vielen anderen Bounded Contexts verwendet. Häufig operiert der querschnittliche Context mit eigenen Daten genauso wie mit Daten der Konsumenten, was die Modellierung erschwert und ein unsauberer Schnitt fatale Folgen für alle Bounded Contexts in diesem Konglomerat haben kann. Zum einen sind die Daten der Konsumenten in der Regel unterschiedlich. Zum anderen müsst ihr entscheiden, welche Informationen ihr für den querschnittlichen Context verständlich bereitstellen müsst, welche ihr in einer für die querschnittliche Fachlichkeit nicht relevanten Form liefern könnt und welche überhaupt nicht betrachtet werden. Das Herausarbeiten und Erhalten einer passenden Schnittmenge und einer gemeinsamen Sprache ist hier eine besondere Herausforderung.

Gerade wenn der querschnittliche Context Fachlichkeit bereitstellt, die nicht zu einer Core Subdomain gezählt werden kann oder dieser Technologie verwendet, die sonst noch nirgends verwendet wird, ist der Druck von anderen Bounded Contexts auf diesen tendenziell größer. Das steigert die Gefahr, dass solche Domänen die Domäne des querschnittlichen Contexts kontaminieren und damit das Komplexität und Abhängigkeiten erhöht. Ein typischer Irrtum zeigt sich hier in Entscheidungen, die nach dem Motto „da haben wir ja schon einen Bounded Context, der querschnittliche Fachlichkeit oder Technologie X bereitstellt“ gefällt werden und die Verantwortlichkeit des Contexts verwässern.

Bei Spotiflix stellen die im Bounded Context „Warenkorb“ enthaltenen Teildomänen „Produktkatalog“ und „Bezahlvorgang“ eine Supporting bzw. Generic Subdomain dar. Der Warenkorb bildet keine Funktionalität ab, mit der sich Spotiflix am Markt abhebt. Wenn der Produktkatalog besonders großartig aufgebaut ist, kauft dennoch keiner bei Spotiflix, wenn das Angebot oder die Streaming-Leistung schlecht ist. Der Produktkatalog wird allerdings zweifelsohne benötigt, er lässt sich aber vielleicht nicht als Softwareprodukt von der Stange kaufen und integrieren.
Ebenso sind die Bezahlvorgänge kein Marktdifferenzierungsfaktor. Nutzer:innen erwarten hier eine einfache und sichere Abwicklung über verschiedene Zahlungswege, was jedoch kein Alleinstellungsmerkmal von Spotiflix ist. Das Thema ist komplex, aber von anderen Software-Anbietern, deren Core Domain „Zahlungsvorgänge“ sind, gelöst. Spotiflix kann diese Funktionalität einkaufen.

Damit ist der Warenkorb aber, weil er zum einen zentral, zum anderen nicht das Herzstück des Unternehmens ist, viel eher Opfer von ungestümer Überfrachtung.
Ein Beispiel? Erinnert Ihr euch noch an das Cover Flow Feature, welches etwa in iTunes zwischen 2006 und 2012 verwendet wurde?
In einer Diskussion zwischen Musik-Streaming- und Warenkorb-Team könnte man etwa auf die Idee kommen, dass so etwas im Produktkatalog und im Musik-Streaming eine nette Sache wäre. Wie im Laden vor Ort könnte man so durch die Platten stöbern. Und wenn es dann im Warenkorb gebaut wurde, weil „die eh schon viel Frontend machen“, kann man es später im Streaming von dort übernehmen.
Vielleicht ist das Feature eine wunderbare Idee. Allerdings ist die Gefahr zunächst einmal hoch, dass nun Dinge im Warenkorb Context landen, die etwa für Filme gar nicht verwendet werden sollen.

Der Bounded Context Musik-Streaming beginnt den Warenkorb zu kontaminieren und macht diesen damit komplexer. Das Risiko, andere Konsumenten der Querschnittsfunktionalität nicht zu beachten und dabei zusätzlich den Warenkorb als „Gehilfen“ der „wichtigeren“ Core Domain zu betrachten, ist hier ungleich höher als in anderen Szenarien.

Abhängigkeiten reduzieren

Die Abhängigkeiten im eigenen System zu kennen und Konsequenzen von Entscheidungen zu verstehen ist die wichtigste Aufgabe, um querschnittliche Fachlichkeit effizient zur Verfügung zu stellen. Danach geht es in die Lösungsfindung, bei welcher ihr versucht, die schwerwiegenden und problematischen Abhängigkeiten aufzulösen oder zu reduzieren. An dieser Stelle diskutieren wir einige allgemeine Hinweise und Prinzipien dazu. Abbildung 5 visualisiert diese Prinzipien passend zu den in Abbildung 3 identifizierten Abhängigkeitsbereichen und den konkreten Abhängigkeiten.

• Datenhaltung: Kategorisiert eure Daten. Die Ubiquituous Language in eurem Bounded Context hilft euch dabei.
  Begriffe, die in einem Context nicht natürlich auftauchen, haben hier vermutlich auch nichts verloren. Wichtig ist, zu identifizieren, über welche Daten ihr tatsächlich die Hoheit habt oder haben solltet.
  Wenn wir uns bei Spotiflix dazu entscheiden würden, die Hoheit über die Filme im Warenkorb zu sehen, würden wir das konsequenterweise auch für die Musik so handhaben. Und auf einmal kümmern wir uns im Warenkorb um Dinge, die hier überhaupt keine Rolle spielen, wie das Speichern von Rohdaten oder das effiziente Komprimieren dieser. Stattdessen sollten wir herausarbeiten, was die vom Warenkorb bereitgestellte Funktionalität ist und welche Daten hier übergreifend benötigt werden. Und das sind weder die Filme noch die Songs, sondern etwa, und das haben Filme und Musik gemein, Dinge wie Titel, Künstler, Erscheinungsdatum, Dauer, käufliche Verfügbarkeit, Cover und Preis. Das bedeutet nicht, dass all diese Dinge nun automatisch im Warenkorb liegen sollten, aber das wären zumindest Kandidaten.
• Schnittstellen: Reduziert die Kopplung, welche über eure Schnittstellen realisiert wird – quantitativ wie qualitativ.
  Identifiziert die Punkte, an welchen der querschnittliche Context mit anderen kommunizieren muss, haltet diese möglichst gering und setzt sie so weit wie möglich an Anfang und Ende von Prozessen. Damit erhöht ihr die Autonomie dieses Bounded Contexts und stellt sicher, dass Prozesse, abgesehen von Einstieg und Ende, komplett von diesem bedient werden können. Muss euer querschnittlicher Context bei der Abarbeitung typischer Use Cases ständig Schnittstellen anderer Bounded Contexts aufrufen, deutet dies auf einen schlechten fachlichen Schnitt hin. Wenn ihr euren Prozess „unit testen“ könnt, ohne einen Zoo an Requests zu mocken, ist das ein gutes Zeichen.
  Asynchrone Kommunikation kann dabei helfen, direkte Kopplung zu reduzieren, insbesondere wenn dadurch Prozesse keine direkten Aufrufe zu anderen Bounded Contexts mehr benötigen. In unserem Beispiel könnten etwa Events wie „Neuer Film hinzugefügt“ oder „Film von Nutzer:in gekauft“ direkte Kommunikation reduzieren. Bedenkt aber, dass dennoch Form und Qualitätsziele dieser Kommunikation betrachtet werden müssen und dass die Fehlererkennung und -Behandlung deutlich erschwert werden kann.
• Entwicklung: Haltet euren querschnittlichen Bounded Context schlank, oder in Anlehnung an ein anderes bekanntes Prinzip in der Software-Entwicklung: KIS – keep it slim.
  Lasst euch nicht in Situationen locken, in welchen euer Context Funktionalität erfüllen muss, weil hier schon ein Teil ist, welcher mit vielen anderen Teilen der Software spricht oder eine gewisse Technologie beherrscht. Dabei hilft es, die Art der durch den Context abgedeckten Subdomänen zu untersuchen. Handelt es sich etwa um Supporting Subdomains, welche keinen Wettbewerbsvorteil bieten, ist dies ein guter Grund, zu viel Verantwortlichkeit und Risiko abzulehnen. Ihr wollt verhindern, dass Contexts, welche Core Subdomains abdecken, diesen querschnittlichen Context kontaminieren und somit auch etwa strategische Entscheidungen wie Outsourcing und Budgetierung ad absurdum führen.
  Denkt bei Features mit Abhängigkeiten zu einem anderen Bounded Context die anderen Konsumenten der Querschnittsfachlichkeit mit und entscheidet, ob dieses Feature hier tatsächlich richtig aufgehoben ist.

Auch für die Überschneidungen der Abhängigkeitsbereiche lassen sich ein paar allgemeine Hinweise und Prinzipien finden:

• Integration: Denkt über verschiedene Integrationsmuster, wie Partnerschaften, Anti Corruption Layer oder Open-host Services nach und macht die Form der Interaktion zwischen Bounded Contexts explizit.
  Stellt die Funktionalität von Schnittstellen etwa über Consumer-driven Contracts sicher und sorgt dafür, dass ihr eine eigene, saubere Ubiquituous Language für euren querschnittlichen Context habt und erhaltet. Hier kann es hilfreich sein, nicht alle benötigten Begriffe aus anderen Contexts zu importieren, sondern eigene Begriffe zu finden. Damit reduziert man die Gefahr von Verwechselungen ggf. auf Kosten größerer Übersetzungsaufwände, welche jedoch explizit sind. Statt also etwa „Song“ und „Film“ im Warenkorb-Context zu verwenden, genügt hier der Begriff „Artikel“, welcher auch agnostisch gegenüber den angrenzenden Contexts ist.
• Datentrennung: Der Standard für die Datenhoheit sollte eine passende Trennung der Daten sein. Jeder Bounded Context hat seine Verantwortlichkeit, die sich auch in der Datenhaltung widerspiegeln sollte. Das reduziert Absprachen bei Format, Technologie und Pflege. Am Ende bleibt das, häufig nur einmalig zu lösende, Problem der Identifikation universell eindeutiger Entitäten, was ein kleineres Problem darstellt.
• Opaque Daten: Akzeptiert Daten von außerhalb, die ihr nicht versteht. Behandelt sie also als opaque, als undurchsichtig. Solche Daten können ggf. angezeigt werden und von verschiedenen Konsumenten des querschnittlichen Contexts unterschiedlich verwendet werden, solange Format und grober Sinn klar sind. So könnte der Warenkorb etwa „Mitwirkende“ bei Filmen und Songs darstellen. Ob das nun aber Schauspieler:innen oder Musiker:innen sind, spielt im Warenkorb keine Rolle. Relevant ist, dass die Information eine Zeichenkette ist und für einen gewissen Zweck genutzt wird. Der Warenkorb muss den Inhalt aber nicht verstehen, geschweige denn damit arbeiten können.
  Auch wenn der Warenkorb mit gewissen Informationen nicht arbeitet, kann es sinnvoll sein, diese Informationen von anderen Contexts zu akzeptieren und bei späterer Kommunikation wieder mitzusenden. So können außenstehende diesen Datensatz z.B. wieder identifizieren.

Fazit

Welche Wege und Prinzipien in einer konkreten Situation Verwendung finden können und sollen, lässt sich nur anhand eben dieser Situation entscheiden. Die Frage, für welche Herausforderungen man Wege und Prinzipien finden sollte, lässt sich durch die Untersuchung der Abhängigkeitsbereiche beantworten. Ein einfaches Modell (vgl. Abbildung 3) kann hier helfen, die Diskussion zu starten und einige häufig auftretenden Fallstricke nicht zu übersehen. Ebenso helfen allgemeine Prinzipien (vgl. Abbildung 5) typische Abhängigkeiten anzugehen.
Am Ende solltet ihr bei sehr großen Herausforderungen und Schwierigkeiten, diese elegant zu lösen, auch nicht davor zurückschrecken, die Frage erneut aufzuwerfen, ob ein querschnittlicher Bounded Context die richtige Entscheidung ist.