Aggregate
Ein Aggregate bündelt Objekte und Regeln, die bei einer Änderung gemeinsam konsistent bleiben müssen. Eine Wurzel kontrolliert alle Änderungen innerhalb dieser Grenze.
- WurzelEinziger Zugang für Änderungen.
- InvarianteRegel, die immer gelten muss.
- KonsistenzgrenzeWas zusammen gültig bleiben muss.
Einordnung
Warum das wichtig ist
Regeln über mehrere Objekte lassen sich nur einhalten, wenn der Zugang kontrolliert ist. Ohne Grenze entstünde eine Bestellung ohne Position oder mit Menge null. Entities und Value Objects behandelt der vorherige Baustein.
Dieser Baustein erklärt transaktionale Konsistenz im Domänenmodell. Für Identität und fachliche Werte siehe Entities und Value Objects.
Auf einen Blick · Wurzel schützt die Konsistenzgrenze
Wer darf was ändern?
Die Bestellung B-1042 enthält Positionen und eine Lieferadresse. Ihre Regeln verlangen mindestens eine Position, eine positive Menge je Position und eine Bestellsumme, die zu den Positionen passt.
So liest du das Bild
- Wurzel Der Kasten Bestellung B-1042 nimmt Änderungsversuche an und prüft sie.
- Invariante Die Checkliste: mindestens eine Position, Menge größer 0, Summe stimmt.
- Konsistenzgrenze Der Bereich Aggregate Bestellung; Zahlung und Reservierung liegen außerhalb.
Aggregate Bestellung
- Bestellung B-1042Aggregate Root (Ziel des Versuchs)
- Position P-7Tasse · Menge 2
- LieferadresseValue Object
- Zahlungeigenes Aggregate · per Kennung
- Reservierungeigenes Aggregate · per Kennung
angenommen
- mindestens eine Position: hält
- Menge je Position größer 0: hält
- Bestellsumme = Summe der Positionen: hält
- positionen
- P-7 · Menge 3
- bestellsumme
- 74,85 EUR
Die Wurzel prüft alle drei Regeln, nimmt die Änderung an und berechnet die Summe neu: 3 mal 24,95 EUR sind 74,85 EUR.
Preise illustrativ
Nutzen & Grenzen
Hilft, wenn
- Mehrere Werte müssen gemeinsam eine fachliche Regel erfüllen.
- Änderungen benötigen einen kontrollierten Zugriff, damit parallele Schreibvorgänge gültige Zustände erhalten.
Grenzen
- Ein zu großes Aggregat verursacht Konkurrenz und lange Transaktionen. Prüfe, welche Regeln wirklich gemeinsam gelten und ordne passende Transaktionsgrenzen zu.
- Nachgelagerte Konsistenz kostet: Die Bestellung ist bestätigt, die Reservierung folgt erst danach. Schlägt sie fehl, braucht es eine Behandlung, etwa eine Saga. Mehr dazu unter Konsistenz.
In der Praxis
- Invarianten zuerst formulieren. Schreibe auf, welche Regeln nach jeder Änderung gelten müssen; diese Konsistenzanforderung bestimmt anschließend die Objektstruktur.
- Wurzel und Grenze wählen. Bestimme, welches Objekt Änderungen kontrolliert und welche Daten für die Invarianten gemeinsam gespeichert werden müssen. Stimme dies mit den relevanten Transaktionsgrenzen ab.
- Konkurrenz und getrennte Vorgänge prüfen. Teste gleichzeitige Änderungen und entscheide, welche Folgeaktionen außerhalb der Grenze stattfinden. Value Objects helfen, gültige Werte innerhalb des Aggregats zu sichern.
Ausführliche Erklärung lesen
Die Aggregatwurzel ist der kontrollierte Zugriffspunkt für Änderungen innerhalb einer Konsistenzgrenze. Sie prüft, ob ein Zustandsübergang gültig ist und die zugehörigen Invarianten erhalten bleiben. Value Objects modellieren unveränderliche Werte im Aggregat; Transaktionsgrenzen helfen, seine atomaren Änderungen festzulegen.
Die Grenze umfasst nur Daten, die gemeinsam konsistent sein müssen. Andere Aggregate werden häufig über Identität referenziert und in eigenen Vorgängen geändert. Das begrenzt Schreibkonflikte und lange Transaktionen, verlangt aber einen bewussten Umgang mit späteren Ergebnissen und Wiederholungen. Die Aggregatgrenze folgt den gemeinsam durchzusetzenden Invarianten; fachlich verbundene Objekte können zu unterschiedlichen Konsistenzgrenzen gehören.
Faustregeln nach Vaughn Vernon („Effective Aggregate Design“) lassen sich in einem Satz zusammenfassen: Aggregate klein halten, andere Aggregate nur über ihre Kennung referenzieren, pro Transaktion nur ein Aggregate ändern und zwischen Aggregaten auf nachgelagerte Konsistenz setzen. Im Shop bleiben Zahlung und Reservierung deshalb eigene Aggregate neben der Bestellung.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Regel verletzt der Versuch, die Menge von P-7 auf 0 zu setzen, und wer lehnt ab?
Lösung mit Begründung ansehen
Die Regel einer Menge größer 0 je Position. Die Wurzel Bestellung B-1042 lehnt die Änderung ab, die Bestellung bleibt bei 49,90 EUR.
AnwendenAuf eine neue Lage übertragen
Zur Bestellung wird eine neue Position mit Menge 1 hinzugefügt (Tasse, 24,95 EUR). Was prüft die Wurzel, und wie ändert sich die Summe?
Lösung mit Begründung ansehen
Die Wurzel prüft, dass die Menge größer 0 ist und mindestens eine Position bleibt. Danach berechnet sie die Summe neu: 49,90 EUR plus 24,95 EUR ergibt 74,85 EUR.
BewertenEine Alternative abwägen
Soll die Reservierung ins Aggregate Bestellung, damit Bestand und Bestellung in einer Transaktion stimmen?
Lösung mit Begründung ansehen
Vorteil: Beides stimmt sofort überein. Nachteil: Das Aggregate wird groß, und Änderungen an Bestand und Bestellung blockieren sich gegenseitig. Empfehlung: Die Reservierung bleibt ein eigenes Aggregate, per Kennung referenziert, und folgt nachgelagert.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
Repository und Factory
Taktisches DDD ergänzt Aggregate durch Factory und Repository. Eine Factory erzeugt ein fachlich gültiges, gegebenenfalls zusammengesetztes Objekt; ein Repository lädt und speichert Aggregate unter ihrer Identität und verbirgt die technische Persistenz. Beide dienen dem Domänenmodell und ersetzen weder die Aggregatwurzel noch deren Invarianten. Das Repository macht aus mehreren Aggregaten auch keine gemeinsame Transaktion; deren Koordination braucht eigene Prozessregeln.
Zum AusprobierenModelliere die Eröffnung einer Bestellung: nutze eine Factory, wenn Kunde, Positionen und Startstatus gemeinsam gültig aufgebaut werden müssen, und ein Repository für Laden und Speichern der Bestellung. Prüfe, dass Änderungen weiterhin über die Aggregatwurzel laufen und Lagerreservierung als eigener Vorgang behandelt wird.
Weiterführende Bausteine
Quellen
- Martin Fowler · DDD Aggregate (öffnet in neuem Tab)Beschreibt Aggregate als Konsistenz- und Zugriffsgrenzen.
- Microsoft · Domain Model (öffnet in neuem Tab)Erklärt Entities, Aggregate und fachliche Invarianten anhand einer Implementierung.
- Microsoft · Tactical DDD (öffnet in neuem Tab)Verbindet Aggregate, Entities und Domänendienste mit Servicegrenzen.
- Vaughn Vernon · Effective Aggregate Design (öffnet in neuem Tab)Die dreiteilige Aufsatzreihe beschreibt die Faustregeln für den Zuschnitt von Aggregates.
- Martin Fowler · Repository (öffnet in neuem Tab)Sammlungsartige Schnittstelle zwischen Domänenobjekten und Persistenz.
- Eric Evans · Domain-Driven Design Reference (öffnet in neuem Tab)Definiert die Rollen von Aggregat, Factory und Repository im Domänenmodell.