Datenhoheit
Datenhoheit verbindet Daten mit dem Baustein, der ihre fachliche Bedeutung und Änderung regelt. Andere Bausteine greifen über vereinbarte Verträge darauf zu.
- BesitzerGenau ein Modul pro Datenart.
- VertragAndere lesen nur, was freigegeben ist.
- Eigene TatsacheEigene Bedeutung statt bloßer Kopie.
Einordnung
Warum das wichtig ist
Ohne Datenhoheit ändern mehrere Module dieselben Daten unter eigenen Annahmen, und niemand verantwortet das Ergebnis. Gemeinsame Speicherung klärt das nicht. Wie Grenzen im Code durchgesetzt werden, zeigt Modulgrenzen; die Versuchung der gemeinsamen Datenbank behandelt der modulare Monolith. Hier geht es um die Zuordnung selbst.
Dieser Baustein erklärt fachliche Verantwortung für Daten. Für technische Transaktionsgrenzen siehe Transaktionsgrenzen.
Auf einen Blick · Ein Besitzer je Datenbestand
Wem gehört welche Datenart?
Im modularen Monolithen liegen Tabellen in einer Datenbank, bleiben aber fachlich einzelnen Modulen zugeordnet. Gemeinsame Speicherung hebt die Datenhoheit nicht auf.
So liest du das Bild
- Besitzer Die Zelle „besitzt und schreibt“ erscheint in jeder Zeile genau einmal.
- Vertrag Die Zellen „liest über Vertrag“ zeigen, wer Daten erhält, ohne sie zu ändern.
- Eigene Tatsache Die hervorgehobene Zeile: Der vereinbarte Preis in B-1042 gehört der Bestellung, nicht dem Katalog.
| Datenart | Katalog | Warenkorb | Bestellung | Zahlung | Lager | Versand | Rechnung |
|---|---|---|---|---|---|---|---|
| kein Zugriff | kein Zugriff | besitzt und schreibt | kein Zugriff | kein Zugriff | liest über Vertrag | liest über Vertrag | |
| kein Zugriff | kein Zugriff | liest über Vertrag | besitzt und schreibt | kein Zugriff | kein Zugriff | liest über Vertrag | |
| kein Zugriff | kein Zugriff | liest über Vertrag | kein Zugriff | besitzt und schreibt | kein Zugriff | kein Zugriff | |
| kein Zugriff | kein Zugriff | liest über Vertrag | kein Zugriff | kein Zugriff | besitzt und schreibt | kein Zugriff | |
| besitzt und schreibt | liest über Vertrag | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | |
| kein Zugriff | kein Zugriff | besitzt und schreibt | kein Zugriff | kein Zugriff | kein Zugriff | liest über Vertrag |
Auftrag und Statusbesitzt und schreibt: Bestellung
Versand meldet über den Vertrag, die Bestellung entscheidet über ihren Status.
Schreiber je Datenart1
Jede Datenart hat genau einen Schreiber; andere lesen über den Vertrag, und die Regeln bleiben geschützt.
Nutzen & Grenzen
Hilft, wenn
- Mehrere Bausteine mit gemeinsamem Datenbedarf profitieren von einem benannten fachlichen Besitzer, der Regeln und verbindliche Änderungen zuordnet.
- Besitzerverträge halten direkte Abhängigkeiten von internen Speicherformen über Dienste und Module hinweg klein.
- Ein klarer Besitzer macht bei abgeleiteten Lese- oder Analysesichten die maßgebliche Quelle erkennbar.
Grenzen
- Ein Besitzer kann bei hoher Änderungsrate zum Engpass werden; miss den Durchsatz und teile fachlich sicher auf.
- Abgeleitete Kopien veralten und sind keine Quelle; eine eigene Tatsache wie der vereinbarte Preis ist es dagegen schon.
- Berichte über mehrere Besitzer brauchen eigene Lesesichten statt Joins über fremde Tabellen; mehr dazu bei CQRS.
In der Praxis
- Bestimme den Besitzer je Datenbereich und verankere diese Zuständigkeit in Code- und Zugriffsrechten. Nur der Besitzer entscheidet verbindlich über Änderungen und fachliche Gültigkeit.
- Kennzeichne veröffentlichte Lesesichten als abgeleitet und dokumentiere ihre Quelle sowie Aktualität. Schreibe Änderungen über den Besitzervertrag, statt dessen interne Speicherung nachzubilden.
- Prüfe Zuständigkeit bei Grenzänderungen. Bounded Context definiert fachliche Grenzen; Shared Database beschreibt die Kopplung gemeinsamer Speicher.
Ausführliche Erklärung lesen
Ein Datenbesitzer ist für Bedeutung, Regeln und verbindliche Änderungen eines fachlichen Datenbereichs verantwortlich. Andere Bausteine lesen freigegebene Sichten oder fordern Änderungen über den Vertrag des Besitzers an. Damit bleiben Invarianten an einer maßgeblichen Stelle durchsetzbar.
Besitz schließt Lebenszyklus, Zugriff, Migration und Korrektur ein. Abgeleitete Sichten können dieselben Informationen enthalten, sind aber nicht automatisch eine zweite Schreibquelle. Ihre Herkunft und Aktualität müssen erkennbar sein, damit Konsumenten die verbindliche Quelle richtig wählen.
Bounded Context beschreibt den fachlichen Geltungsbereich; Shared Database zeigt, wie gemeinsamer Speicher diese Zuständigkeit technisch verwischen kann.
Database per Service ist die konsequente Form bei getrennten Diensten. Im modularen Monolithen genügt eine gemeinsame Datenbank, in der jedes Modul seine Tabellen besitzt.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wer besitzt Bestand und Reservierung, und wer liest sie?
Lösung mit Begründung ansehen
Das Lager besitzt und schreibt sie. Die Bestellung liest über den Vertrag und fordert Reservierungen an.
AnwendenAuf eine neue Lage übertragen
Der Katalog senkt den Tassenpreis auf 19,95 EUR. Was passiert mit dem Preis in B-1042?
Lösung mit Begründung ansehen
Er bleibt bei 24,95 EUR. Der vereinbarte Preis ist eine eigene Tatsache der Bestellung; die 19,95 EUR gelten nur für neue Einkäufe.
BewertenEine Alternative abwägen
Die Rechnung will für einen Bericht direkt Bestell- und Zahlungstabellen joinen. Wie bewertest du das?
Lösung mit Begründung ansehen
Es ist bequem und schnell gebaut, bindet die Rechnung aber an fremde Tabellenformen und umgeht die Besitzer. Besser: eine eigene Lesesicht oder ein Vertrag der Besitzer.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- microservices.io · Database per Service (öffnet in neuem Tab)Beschreibt Datenverantwortung, API-Zugriff und Folgen für Abfragen.
- Martin Fowler · Microservices (öffnet in neuem Tab)Beschreibt Servicegrenzen, Datenverantwortung und organisatorische Konsequenzen.
- Martin Fowler · Bounded Context (öffnet in neuem Tab)Erklärt Modellgrenzen und Beziehungen zwischen unterschiedlichen Fachmodellen.