In einem Besprechungsraum fliegen Haftnotizen über die Tische, Entwickler streiten über Worte wie "Bestellung" und "Order"; zwei Teams reden scheinbar über dasselbe, liefern aber unterschiedliche Regeln und Daten.
Warum es jetzt zählt
Die Architektur wandelt sich: Systeme verteilen sich, Releases werden häufiger und Teams arbeiten autonom; ohne klare Domänengrenzen wachsen Schnittstellen, technische Schulden und Abstimmungskosten exponentiell.
Erste Schritte, die wirken
Beginne mit dem Geschäft: Event Storming oder Workshops bringen Prozesse und Begriffe auf einen Tisch, identifiziere Kernereignisse, Entscheider und unterschiedliche Bedeutungen für denselben Begriff; formuliere dann Kandidaten für Bounded Contexts basierend auf Sprache, Regeln und Besitz von Daten.
Technik trifft Ökonomie
Technisch heißt Abgrenzung: eigene Modelle, eigene Daten und klare Integrationsmuster (Events, APIs, Anti-Corruption-Layer); wirtschaftlich bedeutet sie: schnellere Releases, geringere Koordination und bessere Verantwortlichkeit — aber auch mehr Infrastruktur, Tests und gelegentliche Duplikation von Logik.
Der Laden, der nicht liefern konnte
Ein Onlinehändler teilte Catalog, Pricing und Ordering nicht sauber: Preise lebten in zwei Systemen, das Marketing änderte Preise, ohne die Kasse zu informieren; Resultat: falsche Rechnungen und verlorene Kunden, bis ein Workshop die Verantwortlichkeiten in drei Bounded Contexts verteilte.
Die Bank, die Preise unterschiedlich verstand
In einer Zahlungsplattform hatte das Risk-Team andere Regeln für "Saldo" als das Accounting; anfangs führte eine gemeinsame Datenbank zu Inkonsistenzen, später erlaubte das Trennen in zwei Kontexte unabhängige Modelle und klar definierte Integrationen mittels Events.
Risiken und Chancen
Zu früh zu viele Grenzen zu ziehen kostet: Fragmentierung, doppelten Aufwand, Inkonsistenzen; zu spät zu handeln jedoch frißt Agilität und erhöht Fehleranfälligkeit; die beste Strategie heißt iterieren: kleine Abgrenzungen, immer mit klarer Geschäftsfrage, und technische Muster wie Consumer-Driven Contracts nutzen.
Was Architekten und Entwickler jetzt tun können
Solution- und Software-Architekten moderieren Workshops, übersetzen Geschäftsprozesse in Modelle und wählen Integrationsmuster; Entwickler verfassen klare Schnittstellen, Tests und Verantwortlichkeit; Manager sorgen für organisatorische Ausrichtung nach Conway's Law, damit Teamstrukturen die Architektur stützen.
Kurz gesagt
Gute Kontextgrenzen sind kein Luxus, sondern eine Investition: sie geben Teams Autonomie, machen Modelle verständlich und reduzieren langfristig Kosten — wenn man sie bedacht und iterativ einführt.
