Bounded Context und Domänengrenzen

Bounded Context (BC) ist eine klare Grenze, innerhalb derer eine einzige Ubiquitous Language, konsistente Modelle und Invarianten funktionieren. Innerhalb der Grenze sind die Begriffe eindeutig („Wette“, „Kunde“, „Limit“), und nach außen kommuniziert der Kontext durch Verträge (Ereignisse/Teams) und zieht nicht die semantischen „Schwänze“ anderer Leute nach innen. Gut gewählte Grenzen reduzieren die Konnektivität, vereinfachen die Skalierung und beschleunigen die Produktentwicklung.

1) Warum wir Grenzen brauchen

Verringerung der kognitiven Belastung. Das Team arbeitet mit einem Modell und einer Sprache, nicht mit „dem ganzen Geschäft auf einmal“.
Isolierung von Invarianten. Kritische Regeln (Gleichgewicht ≥ 0, Einzigartigkeit des Logins) leben an einem Ort und werden durch Aggregate geschützt.
Änderungsmanagement. Die Entwicklung des Schemas/der Regeln innerhalb des BC bricht den Nachbarn nicht - es gibt explizite Verträge.
Leistung und Zuverlässigkeit. Innerhalb des BC können Sie ein geeignetes Konsistenzmodell und Speicher auswählen; außen - asynchrone Projektionen.

2) Wie man Bounded Context identifiziert

1. Event Storming: Notieren Sie die Domänenereignisse „Was ist passiert“, dann die Befehle „Was bitten Sie zu tun“, dann die Aggregate „Wer garantiert die Regel“.

2. Sprachcluster: Wo Wörter und Regeln stabil übereinstimmen - potenzielles BC. Wo das Wort „Kunde“ anders bedeutet (Zahler vs Spieler), gibt es deutlich unterschiedliche Kontexte.

3. Invarianten und Eigentum: Was kann nicht gebrochen werden und wer ist verantwortlich? Die Invariante → in das BC, das sie garantieren kann.

4. Wertstrom: Gruppieren Sie Schritte, die sich oft zusammen ändern - das sind Kandidaten für einen BC.

5. Org-Struktur: Wenn ein Teil von einem separaten Team mit separaten KPIs gemacht wird - wahrscheinlich ist es ein separates BC (aber nicht umgekehrt: Die Org-Struktur sollte das Modell nicht blind diktieren).

• Streit um Begriffe („Wette“, „Ticket“, „Runde“ - verschiedene Bedeutungen).
• Die heißeste Invariante „fließt“ durch die Dienste.
• Unterschiedliche SLOs und Veränderungstempo.
• „Dual-write“ zwischen den Modulen aus Gründen der Atomarität.

3) Typische Zusammenhänge (Beispiel Themenbereich)

Identität/KYC - Registrierung, Verifizierungsstufen, Beschränkungsstatus.
Wallet/Ledger - Bilanzen, Buchungen, Reserven, Währungen.
Wetten/Bestellungen - Empfang, Angebote, Berechnung.
Spiel/Runde - Lebenszyklus der Runde, Ergebnisse.
Bonus/Promo - Gebühren, Lieferung, Konvertierung.
Zahlungen - Ein-/Auszahlungen, Status von Zahlungsgateways.
Compliance/Reporting - Berichte, Audits, regulatorische Showcases.
Katalog/Provider Integration - Spiele, Versionen, Status der Anbieter.
Analytics/Read Models - Projektionen und materialisierte Ansichten.

4) Context Map: Wie BCs interagieren

• Customer–Supplier. Ein BC (Lieferant) liefert Ereignisse/Daten, ein anderer (Kunde) passt seine Modelle an.
• Conformist. Der Kunde akzeptiert die Sprache und das Modell des Lieferanten, wie es ist (z. B. das regulatorische Register).
• Partnership. Zwei BCs entwickeln Sprache und Verträge synchron (oft ein Team/Roadmap).
• Shared Kernel. Gemeinsame minimale Hebesprache/Bibliothek, gemeinsam versioniert; Verwenden Sie vorsichtig.
• Anti-Corruption Layer (ACL). Eine Schutzschicht, die fremde Modelle in ihre Sprache übersetzt.
• Open Host Service / Published Language. Öffentliche Protokolle/Schemata, versioniert und dokumentiert.

Übung: Verwenden Sie standardmäßig ACLs und asynchrone Ereignisse; Conformist - nur wenn der Anbieter den Standard diktiert, Shared Kernel - minimal und bewusst.

5) Grenze = Sprache + Modell + Invarianten + Speicher

• Ubiquitous Language. Wörterbuch der Begriffe mit Beispielen.
• Aggregate und Invarianten. Wer die Regeln „hält“ und welche Operationen erlaubt sind.
• Konsistenzmodell. Stark/CP für Geld, EC/causal für Schaufenster.
• Speicher und Indizes. Sie werden unter Invarianten und SLO ausgewählt.
• Austrittsverträge. Ereignisse/Befehle, Schemaversionen, SLO-Lieferung.

Außen: keine direkten SQL/Tabellenabhängigkeiten. Kommunikation - durch Vertrag.

6) Grenzen und Kohärenz (PACELC)

Innerhalb von BC: Wählen Sie ein Modell unter Invarianten (Wallet - Stark, Wetten - Stark an der Rezeption).
Zwischen BC: am häufigsten durch Ereignisse und Projektionen. Wenn Sie eine synchrone Überprüfung benötigen - ein expliziter Befehl mit Deadline und Ablehnung, wenn nicht verfügbar (kein „versteckter“ REST-Aufruf).

7) Antikorruptionsschicht (ACL)

Die Aufgabe der ACL: die fremde Sprache und „schmutzige“ Daten aus dem BC fernzuhalten.

Schema-Mapping: extern 'PaymentStatus = SETTLED' → intern 'LedgerEntry (type = Credit, reason = PsPSettle)'.
Validierung und Anreicherung: Überprüfung von Invarianten, Normalisierung von Zeitzonen, Währungen.
Versionierung: Unterstützung für 'schema _ version' externer Vertrag, Abwärtskompatibilität.
Idempotenz: durch „external _ id “/„ operation _ id“.
Beobachtbarkeit: Trace-Tags' source', 'schema _ version', 'mapping _ id', DLQ für 'giftige' Nachrichten.

8) Grenzen und Daten: Besitz, Projektionen, API

Ownership: Wem gehört die „Wahrheit“? Nur der Besitzer ändert den Eintrag. Der Rest von BC sind Lesemodelle und Links.
Projektionen: denormalisierte Tabellen zum Lesen; werden aus Ereignissen aktualisiert.
API: Befehle (mutieren beim Besitzer) und Abfragen (lesen Projektionen). Keine „End-to-End“ -Updates fremder Daten.

9) Evolution und Versionen

Events und APIs - mit 'schema _ version' und Kompatibilitätsrichtlinie (additive + fallback).
Blau/Grün von BC: Der neue Vertrag 'v2' wird parallel zu 'v1' veröffentlicht, der Verkehr wird schrittweise übersetzt.
Migrationen: für große Veränderungen - neue Projektion/Service, „Zwei-Phasen-Switch“ Lesungen.

10) Testen der Grenzen

Vertragstests: Überprüfung, dass BC den veröffentlichten Vertrag einhält (Produzententests) und den Fremden richtig versteht (Verbrauchertests).
Property-based: Invarianten von Aggregaten innerhalb von BC (Balance, Limits, Unique).
Chaos bei Integrationen: Verzögerungen, Out-of-Order, Duplikate, Schema-Evolution; Vorhandensein von DLQ und einem sicheren Redrive.
NFR-Tests: p95/Spitzenlast am Rand (Event Server/ACL).

11) Beobachtbarkeit und SLO über Grenzen hinweg

Metriken: throughput Ereignisse/Befehle, 'projection _ lag _ ms', 'dlq _ rate', Mapping-Fehler, p95 API.
Tracing: Erforderliche Tags' bc', 'tenant _ id', 'event _ id', 'operation _ id', 'schema _ version'.
Alertas: Überschreitung der Projektionsverzögerung, Zunahme von Befehlsfehlern, „Flap“ -Schema (viel 'schema _ mismatch').

12) Multi-Tenant und Regionen

'tenant _ id' - in den Schlüsseln aller Ereignisse und Projektionen an der Grenze.
Fairness: Grenzen für Veröffentlichungen/Redrive per Tenant, damit „Noise“ nicht das SLO der Nachbarn stört.
Residency: BC-Daten leben in einer „heimischen“ Region; cross-regional - Aggregate/Berichte.

13) Anti-Muster (was zu einer verschwommenen Grenze führt)

Ein gigantischer „Core-Service“. Alles an einem Ort → Transaktionskämpfe, lange Releases, geringe Autonomie.
Tabellarische Integrationen. Direkte SELECT in fremden Tabellen → Fragilität und Paarung nach dem Schema.
Dual-write. Schreiben Sie gleichzeitig in zwei BCs „für die Bequemlichkeit“ → Diskrepanzen und Sabotage von Invarianten.
Standardkonformist. „Wir haben das Modell eines anderen so angenommen, wie es ist“ → das Durchsickern fremder Bedeutungen, die Unmöglichkeit der Evolution.
Versteckte synchrone Anrufe. Ein REST-Aufruf „irgendwo drinnen“ ohne expliziten Vertrag und Deadline → eine unerwartete Abhängigkeit von der Verfügbarkeit.

14) Beispiel für Konturen (Wortschema)

[Wallet/Ledger] <--CP, Leader, Transactions-->
publishes: WalletReserved/Committed v
[Betting] <--CP on bid taking-->
events: BetPlaced/Settled v
[Read Models/Analytics] <--EC projection-->

[Payments] --ACL--> [Wallet/Ledger]
[Provider Integration] --ACL--> [Game/Round]
[Compliance] <-events - [KYC/Identity], -> reports [Reporting]

15) Mini-Hyde nach Wahl der Grenze

1. Formulieren Sie Invarianten und bestimmen Sie, wer sie garantieren kann.
2. Beschreiben Sie das Wörterbuch (10-20 Begriffe) und überprüfen Sie, ob das Team dasselbe Verständnis hat.
3. Zeichnen Sie eine Kontextkarte und Beziehungstypen.
4. Lösen Sie das Konsistenzmodell innerhalb und an den Gelenken.
5. Entwerfen Sie Verträge (Veranstaltungen/Teams) und ACLs.
6. Planen Sie die Beobachtbarkeit (Metriken/Tracing/Alerts) und DLQ/Redrive.
7. Führen Sie Vertragstests und „Sturm“ (Chaos) für Integrationen durch.
8. Fix Governance: Wer die Sprache/das Schema beherrscht, wie die Änderungen vorgenommen werden.

16) Checkliste vor dem Verkauf

• Jeder BC hat ein Wörterbuch, Aggregate und Invarianten.
• Beziehungen auf der Context Map sind definiert und Verträge dokumentiert.
• Integrationen über Ereignisse/Befehle und ACLs, keine direkten SQL-Abhängigkeiten.
• Idempotenz von Teams/Events; Es gibt Outbox/Inbox und DLQ.
• Das Konsistenzmodell (innerhalb/zwischen BC) wird festgelegt und getestet.
• Schaltungsversionierung und Interoperabilitätsstrategie (v1/v2).
• Latenz-/Fehler-/Leistungsmetriken und Alerts werden angepasst.
• Multi-Tenanty- und Data-Residency-Richtlinien werden eingehalten.
• Operating playbooks: schema-mismatch, redrive, rebuild Projektionen.

17) Schnelle Rezepte

Geld und Grenzen: Ein separater BC mit CP und Transaktionen, APIs nur für Teams, Ereignisse als Ergebnis der Wahrheit für Lesungen.
Feeds/Kataloge: BC mit EC, Projektionen und Cache, explizit 'freshness'.
Integrationen mit externen Anbietern: immer über ACLs, Events/Teams, Versionierung von Schaltungen.
Teamwachstum: Ein BC ist ein Team, das Team hat einen „Sprachbesitzer“ und einen „Invarianten-Keeper“.
Refactoring des Monolithen: erst Verträge und ACL, dann physische Trennung.

Schlussfolgerung

Bounded Context ist nicht nur ein Diagramm, sondern ein Arbeitsvertrag über Sprache, Regeln und die Art und Weise der Evolution. Klare Grenzen reduzieren die Konnektivität, beschleunigen Veränderungen und machen das System im Betrieb berechenbar. Trennen Sie nach Bedeutung und Invarianten, schützen Sie die Grenzen von ACLs und Verträgen, messen Sie alles mit Metriken - und Ihre Architektur bleibt flexibel und zuverlässig, selbst wenn Domain und Team schnell wachsen.