"Implementing DDD" von Vernon: Wertobjekt oder nicht?

Auf Seite 382 dieses Buches finden Sie eine Passage über die Verwendung von Wertobjekten in Aggregaten unter der (Entitäts-) Wurzel. Es gibt ein Beispiel dafür Product, das neben anderen Werten eine Set<ProductBacklogItem>Sammlung von Entitäten enthält .

Nun versucht Vernon zu erklären, warum ProductBacklogItemes sich um eine Entität und nicht um ein Wertobjekt handelt:

Es gibt gute Gründe, warum ProductBacklogItem eher als Entität als als Wert modelliert wird. Wie in Wertobjekte (6) erläutert, muss die Sicherungsdatenbank, da sie über den Ruhezustand verwendet wird, Wertesammlungen als Datenbankentitäten modellieren. Das Neuanordnen eines der Elemente kann dazu führen, dass eine erhebliche Anzahl, sogar alle ProductBacklogItem-Instanzen, gelöscht und ersetzt werden. Dies würde tendenziell zu einem erheblichen Overhead in der Infrastruktur führen. Als Entität kann das Bestellattribut für alle Sammlungselemente so oft geändert werden, wie es ein Product Owner benötigt. Wenn wir jedoch von der Verwendung von Hibernate mit MySQL zu einem Schlüsselwertspeicher wechseln, können wir ProductBacklogItem leicht in einen Werttyp ändern. Bei Verwendung eines Schlüsselwerts oder eines Dokumentenspeichers

Ich verstehe nicht, warum die Repository- Implementierung bestimmt, ob ein Modell eine Entität oder ein Wertobjekt sein wird. Wenn wir zum Schlüsselwertspeicher gehen, haben wir möglicherweise noch eine Bestellung, über die er spricht.

Halten Sie das für sinnvoll?

Der Grund dafür ist, dass SQL-Datenbanken die Objekte relational speichern - Elemente werden in einer anderen Tabelle als der aggregierte Stamm gespeichert und verweisen durch IDs auf den aggregierten Stamm zurück. Für die Verwendung von MySQL müssen daher Elemente als Entitäten modelliert werden, die in einer separaten Tabelle gespeichert werden, in der sie die primäre ID erhalten (mit automatischer Inkrementierung).

In Schlüsselwertspeichern z. In MongoDB kann man die gesamte Sammlung von Elementen als Teil des aggregierten Stamms speichern. Die Elemente werden nicht zu separaten Entitäten (in ihrer On-Tabelle) und können daher als Wertobjekte modelliert werden.

Z.B. Blog hat Kommentare als Sammlung gespeichert in:

{
  _id: 1,
  title: 'Some title',
  body: 'Blog body',
  comments: [{
     person: 'John Smith',
     comment: 'First comment of the blog',
     created_at: new Date()
  },
  {
     person: 'Peter Jackson',
     comment: 'Second comment of the blog',
     created_at: new Date()
  }],
}

Ich weiß, dass diese Frage von vor einigen Jahren stammt, aber ich habe mich im Moment mit einem ähnlichen Modellierungsproblem befasst, und vielleicht ist es für andere nützlich, zu sehen, welche alternativen Meinungen es gibt.

Sie haben Recht, dieser Abschnitt ist etwas irreführend und widersprüchlich, da so viel Zeit in DDD verbracht wird, was darauf hinweist, dass das Domain-Design nicht durch Bedenken hinsichtlich der Persistenz bestimmt werden sollte.

Wenn ich eine Vermutung anstelle, wird tatsächlich auf die unveränderliche Natur von Wertobjekten Bezug genommen. In diesem Beispiel spricht er speziell über die Reihenfolge der Backlog-Elemente. Wertobjekte sind unveränderlich. Wenn Sie also die Reihenfolge von 1 Backlog-Element ändern, kann dies dazu führen, dass "eine signifikante Anzahl, sogar alle ProductBacklogItem-Instanzen gelöscht und ersetzt werden".

Obwohl das Wertobjekt technisch immer noch von der Infrastruktur gesteuert wird, um die Ordnung in einer SQL-Lösung aufrechtzuerhalten, muss es veränderlich sein und darf daher kein Wertobjekt sein. Dieses Problem tritt in einer NoSQL-Lösung nicht auf, in der "Aggregatinstanzen normalerweise als Ein-Wert-Darstellung für die Speicherung serialisiert werden". Sie sollten also nicht zulassen, dass die Persistenz Ihr Design bestimmt, aber um eine Neuordnung zu ermöglichen, führt kein Weg daran vorbei, dass das Objekt keine Entität ist

Hier kam mein eigenes Modellierungsproblem ins Spiel. Wenn die Reihenfolge der Elemente wichtig ist, habe ich mit der Idee gerungen, dass diese Objekte Entitäten sein müssen ... denn wenn die Reihenfolge wichtig ist, muss auch die Identifizierung wichtig sein. dh. Wie können Sie Artikel nachbestellen, wenn jeder keine bestimmte Identität hat? Wenn die Reihenfolge nicht wichtig ist, handelt es sich jetzt nur noch um eine Sammlung / einen Beutel mit Werten. Daher handelt es sich jetzt wahrscheinlich um Wertobjekte.

Der Ansatz, den ich in Betracht gezogen habe, ist, dass die Reihenfolge von einer Entität verwaltet werden sollte, in diesem Fall OrderedBackLogItem. Diese Entität enthält jedoch ein ProductBacklogItem-Wertobjekt und ein Bestellattribut.

Andere Alternativen sind der Ansatz, den Vernon gewählt hat (eine Entität), oder die Sammlung selbst ist ein Wertobjekt, sodass die gesamte geordnete Liste jedes Mal zerstört und neu erstellt wird.

Ich bin mir immer noch nicht sicher, ob jedes Element in einer Liste eine Entität sein muss, wenn eine Nachbestellung wichtig ist.