Repository
Das Repository verbirgt Speichermechanik und erhält die Identität und Konsistenzgrenze des Aggregats.
- RepositoryLädt und speichert fachliche Aggregate über ihre Identität.
- AggregateSchützt seine Invarianten innerhalb der Konsistenzgrenze.
- AdapterÜbersetzt den Vertrag in konkrete Speicherzugriffe.
Einordnung
Warum das wichtig ist
Ein Repository als fachlichen Zugang zu gespeicherten Aggregaten gestalten und von Tabellenzugriff unterscheiden.
Laden und Speichern von Aggregaten über einen fachlich passenden Vertrag.
Repository-Vertrag und Tabellenzugriff
Das Bestellmodul besitzt Bestelldaten; Lager verwaltet seine Reservierungen im selben modularen Monolithen.
So liest du das Bild
- Repository Speichervertrag
- Aggregate Konsistenzgrenze
- Adapter Technikgrenze
| Kriterium | Aspekt | Repository |
|---|---|---|
| Verantwortung | Aggregate speichern | Aggregate laden |
| Grenze | Fachliche Identität | Speichertechnik |
Nutzen & Grenzen
Hilft, wenn
- Ein fachliches Aggregat wird über seine Identität geladen und nach gültigen Zustandsänderungen gespeichert.
- Aufrufer sollen den Speicheradapter wechseln können, während der Repository-Vertrag fachliche Aggregate und Abfragen ausdrückt.
Grenzen
- Für einfache CRUD-Anwendungen kann ein zusätzlicher Repository-Vertrag gegenüber dem Datenzugriff wenig fachlichen Nutzen bieten.
- Das Repository schützt weder Aggregatinvarianten noch eine Transaktion über mehrere Aggregate; diese Verantwortung liegt bei Modell und Transaktionsgrenze.
In der Praxis
- Definiere, welche fachliche Identität das Repository lädt und speichert, und beschränke den Vertrag auf diese Aggregate.
- Lass das Aggregat seine Invarianten beim Laden und Ändern durchsetzen. Verstecke Datenbankabfragen, aber keine fachlichen Entscheidungen im Repository.
- Prüfe die Anwendung mit einem Speicheradapter und teste persistenzunabhängige Domänenregeln getrennt. Vermeide Repositorys für jedes einzelne Tabellenobjekt.
Ausführliche Erklärung lesen
Der Vertrag bietet typischerweise eine Suche nach fachlicher Identität und das Speichern geänderter Aggregate. Die konkrete Datenbank, Abfragesprache und Mappinglogik liegen im Adapter.
Das Repository ist nicht die Konsistenzgrenze. Die Aggregatwurzel prüft Invarianten; mehrere Aggregate werden dadurch nicht zu einer gemeinsamen Transaktion. Ein Repository pro Tabelle verwischt häufig die fachliche Modellierung.
Das Repository lädt und speichert das Aggregate; dessen Wurzel schützt fachliche Invarianten.
Eine Factory erzeugt das Aggregat; das Repository kapselt den Speicherzugriff.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Was lädt das Bestellrepository?
Lösung mit Begründung ansehen
Das Bestellaggregat unter seiner Identität.
AnwendenAuf eine neue Lage übertragen
Wo prüfst du, ob der Bestellstatus wechseln darf?
Lösung mit Begründung ansehen
Im Aggregat, das seine Invarianten schützt.
BewertenEine Alternative abwägen
Wann wird ein Repository zu einem technischen Tabellen-DAO?
Lösung mit Begründung ansehen
Wenn sein Vertrag einzelne Speicherzeilen statt fachlicher Aggregate abbildet.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Eric Evans · DDD Reference (öffnet in neuem Tab)Primärreferenz zu Repository- und Factory-Mustern.
- DDD Referenz · Übersetzung (öffnet in neuem Tab)Deutsche Fassung der Referenz von Eric Evans.
- Vaughn Vernon · Implementing Domain-Driven Design (öffnet in neuem Tab)Vertiefung zu taktischen DDD-Bausteinen und Beispielen.