Definition
Der Begriff „Bounded Context“ stammt aus dem Konzept des Domain-Driven Design (DDD), das von Eric Evans in seinem Buch 'Domain-Driven Design: Tackling Complexity in the Heart of Software' aus dem Jahr 2003 eingeführt wurde. Ein Bounded Context bezeichnet einen klar abgegrenzten Bereich innerhalb eines Software-Systems, in dem ein bestimmtes Fachmodell eine eindeutige Bedeutung hat und konsistent verwendet wird.
Innerhalb eines Bounded Contexts wird die Terminologie und das Fachwissen spezifisch definiert, sodass alle Beteiligten, einschließlich Entwickler und Fachanwender, dieselbe Sprache sprechen. Dies verhindert Missverständnisse und fördert die Klarheit in der Kommunikation über das System.
Hintergrund
Die Idee des Bounded Contexts entstand als Reaktion auf die Herausforderungen, die bei der Modellierung komplexer Domänen auftreten. In großen Softwareprojekten können unterschiedliche Teile des Systems unterschiedliche Bedeutungen für denselben Begriff haben, was zu Verwirrung und Inkonsistenzen führt. Der Bounded Context hilft, solche Probleme zu vermeiden, indem er klare Grenzen für die Verwendung von Modellen und Begriffen zieht.
In der Praxis wird ein Bounded Context oft durch organisatorische Strukturen, technische Grenzen oder spezifische Anwendungsfälle definiert. Dies bedeutet, dass verschiedene Teams oder Module innerhalb eines Unternehmens unterschiedliche Bounded Contexts haben können, die jeweils ihre eigenen Modelle und Terminologien verwenden.
Funktionsweise
Ein Bounded Context fungiert als eine Art „Container“ für ein bestimmtes Modell, das die Regeln, Prozesse und Daten innerhalb dieses Kontextes definiert. Die Interaktion zwischen verschiedenen Bounded Contexts erfolgt in der Regel über klar definierte Schnittstellen oder APIs, die den Austausch von Informationen ermöglichen, ohne dass die internen Modelle der einzelnen Kontexte bekannt sein müssen.
Die Implementierung eines Bounded Contexts erfordert eine sorgfältige Analyse der Domäne und der Geschäftsprozesse. Entwickler müssen die Grenzen des Kontexts bestimmen und sicherstellen, dass alle relevanten Aspekte innerhalb dieser Grenzen abgedeckt sind. Dies kann auch die Identifikation von Aggregaten und Entitäten innerhalb des Modells umfassen.
Einsatzgebiete
Bounded Contexts finden Anwendung in der Softwareentwicklung, insbesondere in komplexen Systemen, die aus mehreren Modulen oder Microservices bestehen. Jedes Modul kann als ein separater Bounded Context betrachtet werden, der seine eigene Logik und Datenhaltung hat. Diese Struktur erleichtert die Wartung und Weiterentwicklung des Systems, da Änderungen in einem Kontext keine direkten Auswirkungen auf andere Kontexte haben.
Ein typisches Beispiel für den Einsatz von Bounded Contexts ist ein E-Commerce-System, in dem verschiedene Bereiche wie Produktmanagement, Bestellabwicklung und Kundenservice jeweils eigene Bounded Contexts darstellen. Diese Bereiche können unabhängig voneinander entwickelt und skaliert werden, während sie über definierte Schnittstellen miteinander kommunizieren.
Abgrenzung
Der Begriff Bounded Context wird häufig mit ähnlichen Konzepten wie „Context Map“ oder „Ubiquitous Language“ in Verbindung gebracht. Während ein Bounded Context die spezifischen Grenzen und Modelle definiert, beschreibt eine Context Map die Beziehungen zwischen verschiedenen Bounded Contexts und deren Interaktionen. Die Ubiquitous Language hingegen ist die gemeinsame Sprache, die innerhalb eines Bounded Contexts verwendet wird, um Missverständnisse zu vermeiden.
Ein weiterer verwandter Begriff ist „Microservices“, der oft in Verbindung mit Bounded Contexts verwendet wird. Microservices sind kleine, unabhängige Dienste, die jeweils einen bestimmten Bounded Context repräsentieren können. Der Hauptunterschied besteht darin, dass Bounded Contexts sich auf die fachliche Abgrenzung konzentrieren, während Microservices die technische Implementierung und Bereitstellung von Software betreffen.