Shared Database
Eine Shared Database wird von mehreren Modulen oder Diensten genutzt. Gemeinsame Tabellen können Änderungen, Berechtigungen und Fehlerfolgen über diese Grenzen hinweg koppeln.
- SchreiberGenau ein Eigentümer ändert den Status.
- LeserAndere nutzen einen Vertrag.
- EreignisÄnderungswunsch statt Direktzugriff.
Einordnung
Warum das wichtig ist
Der modulare Shop nutzt eine gemeinsame Datenbank bewusst für lokale Transaktionen und gemeinsamen Betrieb. Klare Schreiber erhalten Fachregeln. Unabhängige Dienste müssen zusätzlich prüfen, ob geteilte Schemas ihre Auslieferung koppeln.
Hier vergleichst du Nutzen und Kopplung gemeinsamer Datenhaltung. Database per Service beschreibt die Alternative für autonome Dienste.
Auf einen Blick · Gemeinsame Datenbank als Kopplung
Schreibhoheit für den Bestellstatus
Im Shop lesen mehrere Module Bestelldaten; das Bestellmodul bleibt alleiniger Schreiber des Bestellstatus. Versand meldet Änderungen über einen Modulvertrag.
So liest du das Bild
- Schreiber Kasten „Bestellmodul“: besitzt Status und Übergangsregeln, Pfeil „Statusübergang schreiben“ zur „Shop-Datenbank“.
- Leser Kasten „Berichte“ mit Pfeil „Statusansicht anfragen“ zum Bestellmodul.
- Ereignis Pfeil „Versandereignis melden“ vom „Versandmodul“ zum „Bestellmodul“.
Breites Diagramm · bei Bedarf seitlich verschieben
Diagramm als Text lesen
- Bestellmodul: Besitzt Status und Übergangsregeln
- Versandmodul: Liefert Versandereignisse
- Berichte: Lesen über freigegebenen Vertrag
- Shop-Datenbank: Bestellstatus wird vom Eigentümer geschrieben
- Versandmodul → Bestellmodul: Versandereignis melden
- Bestellmodul → Shop-Datenbank: Statusübergang schreiben
- Berichte → Bestellmodul: Statusansicht anfragen
Nutzen & Grenzen
Hilft, wenn
- Gemeinsame Transaktionen und Abfragen profitieren von klarer Verantwortung für Daten und Schema.
- Gemeinsam ausgelieferte Module profitieren von lokalem Transaktionsumfang und einem überschaubaren Datenbankbetrieb, solange Schreibrechte und Schemaverantwortung klar bleiben.
Grenzen
- Unbekannte Leser brechen Schemaänderungen; Zugriffe erfassen und Übergänge mit klarem Abschaltkriterium wählen, siehe Datenmigration.
- Gemeinsame Locks und Last koppeln das Laufzeitverhalten; konkurrierende Workloads messen und bei Engpässen trennen.
- Bei unabhängig auslieferbaren Diensten kann ein gemeinsames Schema Änderungen koppeln; prüfe diese konkrete Grenze gegenüber Database per Service.
In der Praxis
- Zugriffe und Datenbereiche inventarisieren. Erfasse für Tabellen und Schemas Leser, Schreiber, Jobs und Migrationen. Verknüpfe jeden Zugriff mit einer fachlichen Verantwortung. Das Ergebnis ist eine nachvollziehbare Kopplungskarte.
- Schreibverantwortung festlegen. Bestimme, welcher Baustein Regeln und Änderungen einer fachlichen Tatsache kontrolliert. Beschränke direkte Schreibrechte anderer Komponenten und dokumentiere erlaubte Leseverträge. Damit wird der gültige Datenpfad sichtbar.
- Änderungen und Last kontrollieren. Prüfe Schemaänderungen mit bekannten Verbrauchern und beobachte Locks, Pools und Wiederherstellung. Plane eine schrittweise Umstellung mit messbarem Ende. Das Ergebnis ist ein sicherer Umgang mit Kopplung und Übergang.
Ausführliche Erklärung lesen
Eine Shared Database ist eine Datenbank, die mehrere Komponenten gemeinsam nutzen. Das kann in einem modularen Monolithen eine dauerhafte, bewusste Entscheidung sein: gemeinsame Transaktionen und ein überschaubarer Betrieb passen zur gemeinsamen Auslieferung. Getrennte Schemas und klar zugewiesene Schreibrechte erhalten die fachliche Datenhoheit.
Gemeinsame Tabellen, Locks, Ressourcen und Schemaänderungen koppeln die Nutzer. Bei unabhängig auslieferbaren Diensten kann diese Kopplung deren Autonomie begrenzen. Database per Service kapselt Datenzugriffe hinter dem Dienstvertrag, bringt dafür zusätzliche Abfragen über Grenzen und Koordination mit sich. Die Wahl folgt Transaktionsbedarf, Teamverantwortung und Betriebszielen.
Im bestehenden Shop bleibt Bestellung der einzige Schreiber ihres Status. Andere Module nutzen vereinbarte Zugänge; der gemeinsame Datenbankserver macht sie weder zu unabhängigen Diensten noch zu einem Distributed Monolith. Eine spätere Trennung benötigt eine überprüfbare Datenmigration.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wer schreibt den Bestellstatus in die Shop-Datenbank?
Lösung mit Begründung ansehen
Das Bestellmodul über die Kante „Statusübergang schreiben“. Versandmodul und Berichte schreiben nicht.
AnwendenAuf eine neue Lage übertragen
Nach dem Versand soll B-1042 als „versendet“ gelten. Wie läuft die Änderung?
Lösung mit Begründung ansehen
Das Versandmodul meldet ein Versandereignis an das Bestellmodul. Dieses prüft den erlaubten Übergang und schreibt den neuen Status in die Datenbank.
BewertenEine Alternative abwägen
Das Versandmodul schreibt den Status zur Vereinfachung selbst. Welchen Vorteil und welches Risiko hat das?
Lösung mit Begründung ansehen
Es spart den Umweg über das Ereignis. Dafür umgeht es die Übergangsregeln des Bestellmoduls, und Änderungen am Statusfeld betreffen dann mehrere Module.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Microservices.io – Shared database (öffnet in neuem Tab)Beschreibt Nutzen und Kopplungsrisiken einer gemeinsam verwendeten Datenbank.
- Microservices.io – Database per service (öffnet in neuem Tab)Erklärt Datenhoheit und alternative Zugriffswege zwischen Diensten.
- Microsoft – Data considerations for microservices (öffnet in neuem Tab)Behandelt Datenautonomie, Konsistenz und dienstübergreifende Datenzugriffe.