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
Wenn mehrere Module dieselben Daten ändern, kennt niemand mehr die gültigen Regeln, und Änderungen am Schema treffen alle zugleich. Ein klarer Schreiber hält Statusregeln zusammen. Die Betriebsfolgen behandelt Distributed Monolith.
Dieser Baustein behandelt Verantwortung für gemeinsam genutzte Daten. Modulgrenzen ordnen fachliche Eigentümerschaft; Distributed Monolith betrachtet daraus entstehende Betriebskopplung.
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.
- Ein schrittweiser Übergang zu getrennten Datenverantwortlichkeiten braucht sichtbare Zugriffs- und Migrationsregeln.
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.
- Ein Modulvertrag ersetzt die geteilte Tabelle nicht von selbst; die Folgen im Betrieb beschreibt Distributed Monolith.
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 ein Speicher, auf den mehrere Komponenten zugreifen. Ein gemeinsamer Server mit getrennten Schemas und Rechten unterscheidet sich von beliebigen Lese- und Schreibzugriffen auf dieselben Tabellen. Gemeinsame Transaktionen erleichtern bestimmte Abläufe, während Schema, Ressourcen und Wiederherstellung Verbraucher koppeln. Die zentrale Entwurfsfrage ist Datenhoheit, besonders bei geplanten Datenmigration.
Ein verantwortlicher Schreiber bündelt fachliche Regeln und kontrolliert Schemaänderungen. Leser können über dokumentierte Verträge oder geeignete Projektionen angebunden werden. Datenbankrechte, Zugriffsinventar und Metriken zu Locks und Last zeigen tatsächliche Abhängigkeiten. Die gemeinsame Datenbank kann eine bewusste Übergangslösung sein, wenn ihre Folgen und ihr Weiterentwicklungspfad klar bleiben. Schemata, Besitzer und Zugriffsregeln legen fest, welche Tabellen und Schreibrechte gemeinsam genutzt werden und wie stark die Komponenten gekoppelt sind.
Database per Service weist jedem Dienst eine eigene Datenhaltung zu und ist die Gegenform zur gemeinsam genutzten Datenbank.
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.