Zwei Bestellungen haben dieselben Felder, aber verschiedene Nummern. Gleich oder verschieden?

Verschiedene Entities, wenn die Bestellnummer ihre Identität festlegt.

Warum reicht eine Datenbank-ID allein nicht zur Modellentscheidung?

Das Modell muss festlegen, ob und wie diese Kennung fachlich Identität ausdrückt.

Eigenständiger BegriffBegriffKapitel I · Domäne · Baustein 9 von 18

Entity

Entities repräsentieren fachliche Dinge, die trotz Zustandsänderungen wiedererkannt werden.

Von Michael Meierhoff · Meierhoff Systems

IdentitätDie Bestellkennung verbindet den Lebenszyklus.
ZustandAttribute dürfen sich fachlich gültig ändern.
VergleichGleiche Felder ersetzen keine gemeinsame Identität.

Einordnung

Warum das wichtig ist

Der Status einer Bestellung ändert sich. Ihre Identität verbindet diese Zustände zu einem einzigen fachlichen Vorgang. Zwei Bestellungen mit gleichen Positionen bleiben dagegen zwei verschiedene Vorgänge.

Identität, Lebenszyklus und Verhalten im Kontext eines Domänenmodells.

Auf einen Blick · Identität bleibt

Zustände ändern sich entlang derselben Identität.

Shop-Beispiel · Gleichheitstest

Gleiche Bestellung, anderer Zustand

Verfolge B-1042 vom Anlegen bis zur Bestätigung. Vergleiche danach B-1042 mit der hypothetischen zweiten Bestellung B-1043: Gleiche Positionen machen daraus keine gemeinsame Bestellung.

So liest du das Bild

Identität B-1042 bleibt auf beiden Seiten gleich.
Zustand Der Status wechselt von angelegt zu bestätigt.
Vergleich B-1043 bleibt trotz gleicher Positionen eine andere Bestellung.

Bestellung

nummerB-1042 (Vergleichsfeld)
statusangelegt
positionen2 Tassen

Bestellung

nummerB-1042 (Vergleichsfeld)
statusbestätigt
positionen2 Tassen

dieselbe BestellungVergleich über Kennung. Die Kennung ist gleich. Der Status darf sich im Lebenszyklus ändern, die Bestellung bleibt dieselbe.

Wähle ein Paar. Die hervorgehobene Bestellkennung entscheidet über Identität; unterstrichene Werte zeigen Unterschiede.

Eine Geldsumme braucht einen anderen Vergleich: Betrag und Währung gemeinsam.Wertgleichheit ausprobieren

Ein Vorgang über die Zeit

01
B-1042 · angelegt
Die Bestellung bekommt ihre Identität und enthält zwei Tassen.
02
Zahlung autorisiert
Die Zahlungsantwort gehört über ihre Korrelation zur Bestellung B-1042.
03
B-1042 · bestätigt
Der Bestellstatus wird aktualisiert. Die Identität bleibt erhalten.

Die Zustandsfolge ist vereinfacht. Welche Übergänge erlaubt sind, bestimmen die Regeln im Bestellmodul.

Nutzen & Grenzen

Hilft, wenn

Der Gegenstand ändert Zustand, während das Geschäft ihn weiter als dieselbe Sache erkennt.
Beziehungen und Historie hängen an einer stabilen Identität.

Grenzen

Ein technischer Datenbankschlüssel ist nur dann fachlich sinnvoll, wenn das Modell ihn als Identität verwendet.
Identität allein schützt keine Invarianten; dafür braucht es ein zuständiges Aggregat und gültige Operationen.

In der Praxis

Benenne, woran Fachleute eine Instanz trotz geänderter Merkmale wiedererkennen. Validere Kennung und Lebenszyklus gemeinsam und prüfe, ob zwei fachlich gleiche Nummern tatsächlich dieselbe Sache bezeichnen.
Definiere erlaubte Zustandsübergänge und ordne die Entity einer passenden Konsistenzgrenze zu. Prüfe, ob Beziehungen, Historie und fachliche Entscheidungen an derselben Identität hängen.
Vergleiche zwei Objekte mit gleichen Attributen und unterschiedlichen Kennungen. Dokumentiere, ob sie fachlich verschieden bleiben und welche Regeln diese Unterscheidung im Modell sichtbar machen.

Ausführliche Erklärung lesen

Identität wird im jeweiligen Modellkontext festgelegt. Sie kann eine Geschäftsnummer, ein zusammengesetzter Schlüssel oder eine technische Kennung sein, sofern der Kontext sie als dauerhaftes Wiedererkennungsmerkmal nutzt. Gleiche Attribute bedeuten keine gleiche Entity.

Entity-Verhalten hält Zustandsänderungen fachlich gültig. Aggregate ordnen Entities in eine Konsistenzgrenze ein; eine Entity außerhalb eines Aggregats ist nicht automatisch eine unabhängige Transaktionsgrenze.

Entities werden in einer Konsistenzgrenze wie dem Aggregate verwaltet; wertbasierte Daten beschreibt das Value Object.

Selbst prüfen

Teste dich in drei Stufen

AblesenIm Bild nachsehen
Welche Eigenschaft bleibt bei Bestellung B-1042 stabil?
Lösung mit Begründung ansehen
Ihre Bestellidentität.
AnwendenAuf eine neue Lage übertragen
Zwei Bestellungen haben dieselben Felder, aber verschiedene Nummern. Gleich oder verschieden?
Lösung mit Begründung ansehen
Verschiedene Entities, wenn die Bestellnummer ihre Identität festlegt.
BewertenEine Alternative abwägen
Warum reicht eine Datenbank-ID allein nicht zur Modellentscheidung?
Lösung mit Begründung ansehen
Das Modell muss festlegen, ob und wie diese Kennung fachlich Identität ausdrückt.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

Quellen

Weiter im Lernpfad

Als Nächstes in Domänenmodellierung & DDD: Aggregate.

18 Bausteine

Weiter mitAggregate