Entities & Value Objects
Entities werden über ihre Identität und ihren Lebenszyklus unterschieden. Value Objects werden vollständig durch ihre fachlichen Werte beschrieben.
- EntityGleiche Kennung bedeutet dasselbe Objekt.
- Value ObjectGleiche Werte bedeuten gleich.
- Vergleich überEntity über Kennung, Wert über alle Werte.
Einordnung
Warum das wichtig ist
Wer Identität und Wert verwechselt, erhält falsches Gleichheitsverhalten: Bestellungen werden nach Feldern verglichen, Beträge wie Einzelobjekte verfolgt. Dazu zählt Primitive Obsession: Ein Betrag als nackte Zahl kennt keine Währung, und Geld gehört nie in eine Gleitkommazahl. Die Konsistenzgrenze mehrerer Objekte behandelt der Baustein Aggregate.
Dieser Baustein erklärt Identität und Wertgleichheit. Für die gemeinsame Konsistenzgrenze mehrerer Objekte siehe Aggregate.
Auf einen Blick · Identität gegen Werte
Ist das dasselbe?
Die Bestellung B-1042 bleibt trotz Statusänderung dieselbe Bestellung. Zwei Geldbeträge von 49,90 EUR sind fachlich gleich, sobald Betrag und Währung übereinstimmen.
So liest du das Bild
- Entity Bestellung B-1042 vorher und nachher: Kennung gleich, Status anders, trotzdem dieselbe.
- Value Object Geldbetrag 49,90 EUR: Betrag und Währung hervorgehoben, beide Seiten gleich.
- Vergleich über Die hervorgehobenen Felder zeigen je Paar, worüber verglichen wird.
Bestellung
nummerB-1042 (Vergleichsfeld)statusangelegtpositionen2 Tassen
Bestellung
nummerB-1042 (Vergleichsfeld)statusbestätigtpositionen2 Tassen
dieselbe BestellungVergleich über Kennung. Die Kennung ist gleich. Der Status darf sich im Lebenszyklus ändern, die Bestellung bleibt dieselbe.
Entity und Value Object im Vergleich
| Merkmal | Entity | Value Object |
|---|---|---|
| Shop-Beispiel | Bestellung B-1042 | Geldbetrag 49,90 EUR |
| Gleichheit | gleiche Bestellkennung | gleicher Betrag und gleiche Währung |
| Änderung | Status ändert sich über Lebenszyklus | neuer Wert ersetzt alten Wert |
| Bedeutung | dieselbe Bestellung verfolgen | fachlichen Wert ausdrücken |
Nutzen & Grenzen
Hilft, wenn
- Primitive Felder erlauben ungültige oder widersprüchliche Kombinationen.
- Mehrere Werte werden gemeinsam validiert, verglichen oder berechnet.
Grenzen
- Nicht jede Zahl braucht ein Value Object. Zu viele Kleinstwerte blähen den Code auf. Es lohnt sich dort, wo Regeln, Validierung oder Rechnen am Wert hängen, etwa bei Geldbetrag mit Währung.
- Speichern kostet: Werte brauchen eine Abbildung, etwa eingebettete Spalten, und viele ORMs erwarten für Objekte eine Kennung. Plane diese Abbildung in der Persistenz von Anfang an mit ein.
In der Praxis
- Fachliche Bedeutung und Bestandteile bestimmen. Gruppiere Werte, die zusammen eine Regel oder Einheit bilden. Das Ergebnis ersetzt unklare primitive Felder durch ein benanntes Konzept.
- Validierung und Gleichheit definieren. Lege fest, welche Kombinationen zulässig und wann zwei Werte fachlich gleich sind. Nutze die DDD-Modellierung, um diese Bedeutung mit Fachexperten abzustimmen.
- Operationen am Wert absichern. Biete nur Rechen- oder Vergleichsoperationen an, die für gültige Werte Sinn ergeben. Prüfe, wie das Value Object in einem Aggregat zu dessen Invarianten beiträgt.
- Primitive Obsession ablösen. Ersetze betrag: number durch Geldbetrag(4990 Cent, EUR) und prüfe die Zulässigkeit beim Erzeugen. Halte Geld in der kleinsten Einheit statt als Gleitkommazahl, damit Rundungsfehler gar nicht erst entstehen.
Ausführliche Erklärung lesen
Ein Value Object fasst Eigenschaften zusammen, die gemeinsam eine fachliche Bedeutung bilden. Gleichheit ergibt sich aus diesen Bestandteilen; Änderungen werden häufig durch einen neuen Wert dargestellt. Validierung bei der Erzeugung verhindert unzulässige Zustände. Entities unterscheiden sich durch stabile Identität; Aggregates nutzen Werte, um Invarianten innerhalb einer Grenze auszudrücken. Das übergeordnete Domain-Driven Design ordnet beide Konzepte in ein fachliches Modell ein.
Value Objects eignen sich für unveränderliche Konzepte mit wohldefinierten Operationen. Ihre Gleichheitsregeln müssen fachlich klar sein; technische Referenzgleichheit reicht nicht. Werte sollten keine veränderlichen inneren Zustände teilen, damit Gleichheit und Validierung über ihre Lebensdauer gültig bleiben.
Eine unveränderliche Oberfläche genügt nicht, wenn innere Referenzen veränderlich bleiben. Werte teilen daher keinen veränderlichen Zustand, sonst ändert sich ein Wert, ohne dass jemand ihn ersetzt hat.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Warum gelten 49,90 EUR und 49,90 USD als verschiedene Werte, obwohl der Betrag gleich ist?
Lösung mit Begründung ansehen
Verglichen werden Betrag und Währung gemeinsam. Weicht eines der beiden Felder ab, ist es ein anderer Wert.
AnwendenAuf eine neue Lage übertragen
Eine Position über 49,90 EUR wird auf 44,90 EUR rabattiert. Was geschieht mit dem Wert?
Lösung mit Begründung ansehen
Der alte Wert wird nicht verändert, sondern durch einen neuen Geldbetrag von 44,90 EUR ersetzt.
BewertenEine Alternative abwägen
Ist eine Adresse ein Value Object oder eine Entity?
Lösung mit Begründung ansehen
Das hängt vom Kontext ab. In der Bestellung zählen nur die Angaben, also ein Wert. Eine Kundenverwaltung mit Adressbuch kann sie als Entity führen. Welcher Kontext gilt, klärt der Bounded Context.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Martin Fowler · Value Object (öffnet in neuem Tab)Unterscheidet wertbasierte Gleichheit von Objektidentität.
- Microsoft · Implement Value Objects (öffnet in neuem Tab)Zeigt Gleichheit, Unveränderlichkeit und praktische Implementierung von Wertobjekten.
- Microsoft · Domain Model (öffnet in neuem Tab)Erklärt Entities, Aggregate und fachliche Invarianten anhand einer Implementierung.