Frage Value vs Entity Objekte (Domain Driven Design)


Ich habe gerade angefangen, DDD zu lesen. Ich bin nicht in der Lage, das Konzept von Entity vs Value-Objekten vollständig zu verstehen. Kann jemand bitte die Probleme (Wartbarkeit, Leistung, etc.) erklären, denen ein System begegnen könnte, wenn ein Value-Objekt als Entity-Objekt entworfen wird? Beispiel wäre toll ...


76
2017-09-16 18:27


Ursprung


Antworten:


Auf den wesentlichen Unterschied reduziert, ist Identität für Entitäten von Bedeutung, spielt aber für Wertobjekte keine Rolle. Zum Beispiel ist jemandes Name ein Wertobjekt. Eine Customer-Entität kann aus einem Kundennamen (Wertobjekt), List <Order> OrderHistory (Liste von Entitäten) und möglicherweise einer Standardadresse (in der Regel ein Wertobjekt) bestehen. Die Kundeneinheit hätte eine ID, und jede Bestellung hätte eine ID, aber ein Name sollte nicht; Im Allgemeinen spielt innerhalb des Objektmodells die Identität einer Adresse wahrscheinlich keine Rolle.

Wertobjekte können typischerweise als unveränderliche Objekte dargestellt werden; Wenn Sie eine Eigenschaft eines Wertobjekts ändern, wird das alte Objekt im Wesentlichen zerstört und ein neues erstellt, da Sie sich nicht so sehr mit der Identität als mit dem Inhalt beschäftigen. Die Equals-Instanzmethode für Name würde richtigerweise "true" zurückgeben, solange die Objekteigenschaften mit den Eigenschaften einer anderen Instanz identisch sind.

Wenn Sie jedoch ein Attribut einer Entität wie Customer ändern, wird der Kunde nicht zerstört. Eine Kundeneinheit ist normalerweise änderbar. Die Identität bleibt gleich (zumindest sobald das Objekt persistent ist).

Sie erstellen wahrscheinlich Wertobjekte, ohne es zu merken. Immer wenn Sie einen Aspekt einer Entität darstellen, indem Sie eine feinkörnige Klasse erstellen, haben Sie ein Wertobjekt. Zum Beispiel wäre eine Klasse IPAddress, die einige Einschränkungen für gültige Werte hat, aber aus einfacheren Datentypen besteht, ein Wertobjekt. Eine EmailAddress könnte eine Zeichenfolge oder ein Wertobjekt mit einem eigenen Verhalten sein.

Es ist durchaus möglich, dass auch Elemente mit einer Identität in Ihrer Datenbank keine Identität in Ihrem Objektmodell haben. Der einfachste Fall ist jedoch eine Zusammensetzung einiger Attribute, die zusammen Sinn ergeben. Sie möchten wahrscheinlich Customer.FirstName, Customer.LastName, Customer.MiddleInitial und Customer.Title nicht haben, wenn Sie diese zusammen als Customer.Name erstellen können; Wenn Sie über Persistenz nachdenken, sind sie wahrscheinlich mehrere Felder in Ihrer Datenbank, aber Ihr Objektmodell ist nicht wichtig.


89
2017-09-16 19:03



Jedes Objekt, das gemeinsam von allen Attributen definiert wird, ist ein Wertobjekt. Wenn sich eines der Attribute ändert, haben Sie eine neue Instanz eines Wertobjekts. Aus diesem Grund sind Wertobjekte als unveränderlich definiert.

Wenn das Objekt nicht vollständig durch alle Attribute definiert ist, gibt es eine Teilmenge von Attributen, die die Identität des Objekts ausmachen. Die verbleibenden Attribute können sich ändern, ohne das Objekt neu zu definieren. Diese Art von Objekt kann nicht als unveränderlich definiert werden.

Ein einfacherer Weg, diese Unterscheidung zu treffen, besteht darin, Wertobjekte als statische Daten zu betrachten, die sich niemals ändern, und Entitäten als Daten, die sich in Ihrer Anwendung entwickeln.


29
2017-10-21 12:19



Ich weiß nicht, ob das Folgende korrekt ist, aber ich würde sagen, dass wir im Falle eines Address-Objekts es als ein Value-Objekt anstelle einer Entität verwenden möchten, da Änderungen an der Entity sich auf alle verknüpften Objekte auswirken würden ( eine Person zum Beispiel).

Nehmen Sie diesen Fall: Sie leben in Ihrem Haus mit einigen anderen Menschen. Wenn wir Entität für Adresse verwenden würden, würde ich argumentieren, dass es eine eindeutige Adresse geben würde, auf die alle Personenobjekte verweisen. Wenn eine Person auszieht, möchten Sie ihre Adresse aktualisieren. Wenn Sie die Eigenschaften der Adresseinheit aktualisieren würden, hätten alle Personen eine andere Adresse. Im Falle eines Value-Objekts wären wir nicht in der Lage, die Adresse zu bearbeiten (da sie unveränderlich ist), und wir wären gezwungen, eine neue Adresse für diese Person anzugeben.

Klingt das richtig? Ich muss sagen, dass ich auch über diesen Unterschied verwirrt war, nachdem ich das DDD-Buch gelesen hatte.

Gehen Sie einen Schritt weiter, wie würde das in der Datenbank modelliert? Würden Sie alle Eigenschaften des Address-Objekts als Spalten in der Person-Tabelle haben oder würden Sie eine separate Adreßtabelle erstellen, die auch eine eindeutige Kennung hätte? Im letzteren Fall würden die Personen, die im selben Haus leben, jeweils eine andere Instanz eines Address-Objekts haben, aber diese Objekte wären bis auf ihre ID-Eigenschaft identisch.


6
2017-09-18 10:07



Adresse kann Entitäts- oder Wertobjekt sein, das vom Geschäftsprozess abhängt. Adressobjekt kann Entität in Kurierdienstanwendung sein, aber Adresse kann Wertobjekt in einer anderen Anwendung sein. in der Kurieranwendungsidentität kommt es auf das Adressobjekt an


3
2018-03-18 12:59



Ich fragte darüber in einem anderen Thread und ich denke, ich bin immer noch verwirrt. Ich kann Leistungsüberlegungen mit der Datenmodellierung verwechseln. In unserer Katalogisierungsanwendung ändert sich ein Kunde erst, wenn es erforderlich ist. Das hört sich doof an - aber das 'Lesen' von Kundendaten ist den "Schreibvorgängen" bei weitem überlegen, und da viele Webanfragen alle auf das "aktive Set" von Objekten treffen, möchte ich Kunden nicht immer wieder aufladen. So ging ich eine unveränderliche Straße für das Kundenobjekt - lade es, speichere es und liefere dasselbe auf die 99% der (Multi-Threaded) Anfragen, die den Kunden sehen wollen. Wenn ein Kunde etwas ändert, rufen Sie einen "Editor" auf, um einen neuen Kunden zu erstellen und den alten Kunden ungültig zu machen.

Meine Sorge ist, wenn viele Threads das gleiche Kundenobjekt sehen und es änderbar ist, dann, wenn ein Thread beginnt, sich zu ändern, kann es in den anderen passieren.

Meine Probleme sind jetzt, 1) ist das vernünftig, und 2) wie man das am besten tut, ohne viel Code über die Eigenschaften zu kopieren.


2
2018-04-21 13:41



Werttypen: 

  • Werttypen existieren nicht allein, abhängig von Entitätstypen.
  • Das Objekt Werttyp gehört zu einem Entitätstypobjekt.
  • Die Lebensdauer einer Werttypinstanz ist durch die Lebensdauer der Entitätsinstanz begrenzt.
  • Drei Werttypen: Basic (primitive Datentypen), Composite (Adresse) und Collection (Map, List, Arrays)

Entitäten: 

  • Entitätstypen können selbst existieren (Identität)
  • Ein Unternehmen hat seinen eigenen Lebenszyklus. Es kann unabhängig von einer anderen Entität existieren.
  • Zum Beispiel: Person, Organisation, Hochschule, Mobil, Zuhause usw. Jedes Objekt hat seine eigene Identität

1
2018-01-28 04:24



3 Unterscheidung zwischen Entities und Value Objects 

  • Identifikator vs strukturelle Gleichheit: Entitäten haben eine Kennung, Entitäten sind gleich, wenn sie dieselbe haben Kennung. Wert Objekte jenseits der Hand haben strukturelle Gleichheit, wir betrachten zwei Wertobjekte gleich, wenn alle Felder gleich sind. Wertobjekte können nicht habe eine Kennung.

  • Mutabilität vs Unveränderlichkeit: Wertobjekte sind unveränderliche Datenstrukturen, während sich Entitäten während ändern ihre Lebenszeit.

  • Lebensdauer: Wert Objekte sollten zu Entitäten gehören


0
2017-11-21 20:40