DDD: Sollte alles entweder in ein Entity oder ein Value Object passen?

Question

Ich versuche, der DDD zu folgen, oder zumindest meinem begrenzten Verständnis davon.

Ich habe allerdings Schwierigkeiten, einige Dinge in die DDD-Kästen unterzubringen.

Ein Beispiel: Ich habe eine Benutzer-Entität. Diese Benutzer-Entität hat einen Verweis auf ein UserPreferencesInfo-Objekt - dies ist nur eine Klasse, die eine Reihe von Eigenschaften bezüglich der Benutzerpräferenzen enthält. Diese Eigenschaften haben nichts miteinander zu tun, außer der Tatsache, dass es sich um Benutzerpräferenzen handelt (anders als z. B. bei einer Address VO, wo alle Eigenschaften ein sinnvolles Ganzes bilden).

Die Frage ist - was ist dieses UserPreferencesInfo-Objekt?

1) Offensichtlich ist es nicht eine Entität (ich speichere es nur als "Komponente" in fließenden nhibernate sprechen (d.h. in der gleichen DB-Tabelle wie die Entität Benutzer).

2) VO? Ich verstehe, dass Value Objects sein sollen Unveränderlich (Sie können sie also nicht abschneiden, sondern nur neu anfertigen). Das macht durchaus Sinn, wenn es sich bei dem Objekt beispielsweise um eine Adresse handelt (die Adresseigenschaften bilden ein sinnvolles "Ganzes"). Aber im Fall von UserPreferencesInfo halte ich es nicht für sinnvoll. Es könnte 100 Eigenschaften geben (Realistisch gesehen) könnte es vielleicht 20 Eigenschaften dieses Objekts geben - warum sollte ich das Objekt verwerfen und neu erstellen wollen, wenn ich eine Eigenschaft ändern muss?

Ich habe das Gefühl, dass ich hier gegen die Regeln verstoßen muss, um das zu bekommen, was ich brauche, aber die Vorstellung davon gefällt mir nicht wirklich (es ist ein schlüpfriger Hang!). Übersehe ich hier etwas?

Gracias

Answer 1

Antwort 1 (die praktische Frage)

Ich bin ein großer Befürworter von DDD, aber man sollte es nicht erzwingen. Sie haben bereits erkannt, dass unveränderliche VOs mehr Arbeit machen, als erforderlich ist. DDD wurde entwickelt, um die Komplexität in den Griff zu bekommen, aber in diesem Fall gibt es sehr wenig Komplexität zu verwalten.

Ich würde einfach behandeln UserPreferencesInfo als Entität und referenzieren Sie es in der User Aggregat. Ob Sie es als Komponente oder in einer separaten Tabelle speichern, bleibt Ihnen überlassen.

IMHO kann die ganze Entity vs. VO Debatte überflüssig gemacht werden. Es ist höchst unwahrscheinlich, dass sich in 6 Monaten ein anderer Entwickler Ihren Code ansieht und sagt: " WTF! Er benutzt keine unveränderlichen VOs! Was zum Teufel hat er sich dabei gedacht?! ".

Antwort 2 (der DDD-Purist)

Ist UserPreferencesInfo tatsächlich Teil des Geschäftsbereichs? Andere haben erwähnt, dass dieses Objekt disjunkt ist. Aber wenn Sie sich an reines DDD halten, müssen Sie möglicherweise bestimmen, welche Präferenzen zu welchem Objekt gehören. Begrenzter Kontext .

Dies wiederum könnte dazu führen, dass zusätzliche Service-Schichten und ehe man sich versieht, hat man die Lösung für ein sehr einfaches Problem überarbeitet...

Answer 2

Hier sind meine zwei Cent. Kurze Antwort: UserPreferenceInfo ist ein Wertobjekt, weil es die Eigenschaften eines Objekts beschreibt. Es ist keine Entität, weil es keine Notwendigkeit gibt, eine Objektinstanz über die Zeit zu verfolgen.

Längere Antwort: ein Objekt mit 100+ Eigenschaften, die nicht miteinander verbunden sind, ist nicht sehr DDD-isch. Versuchen Sie, verwandte Eigenschaften zu gruppieren, um neue VOs zu bilden, oder Sie könnten auch neue Entitäten entdecken.

Ein weiterer DDD-Geruch ist die Tatsache, dass viele Eigenschaften von vornherein festgelegt sind. Versuchen Sie, die Essenz der Aktion zu finden, anstatt nur den Wert zu setzen. Beispiel:

// not ddd 
employee.Salary = newSalary;

// more ddd
employee.GiveRaise(newSalary);

Andererseits kann es durchaus legitime Gründe geben, eine Reihe von Eigenschaften zu haben, die nicht mehr als Getter und Setter sind. Aber dann gibt es wahrscheinlich einfachere Methoden als DDD, um das Problem zu lösen. Es ist nichts falsch daran, die besten Muster und Ideen aus DDD zu übernehmen, aber alle "Regeln" ein wenig zu lockern, insbesondere für einfachere Bereiche.

Answer 3

Ich würde sagen, eine UserPreferenceInfo ist eigentlich ein Teil des User Aggregate Root. Es sollte in der Verantwortung des UserRepository liegen, die User Aggregate Root zu persistieren.

Wertobjekte müssen nur dann neu angelegt werden (in Ihrem Objektmodell), wenn ihre Werte gemeinsam genutzt werden. Ein Beispielszenario dafür wäre, wenn Sie nach einer ähnlichen UserPreferenceInfo suchen und den Benutzer mit dieser verknüpfen, anstatt jedes Mal eine neue einzufügen. Die gemeinsame Nutzung von Wertobjekten ist sinnvoll, wenn Wertobjekttabellen zu groß werden und Probleme mit der Geschwindigkeit und dem Speicherplatz verursachen würden. Der Preis für die gemeinsame Nutzung wird beim Einfügen bezahlt. Es ist sinnvoll, dieses Verfahren in der DAL zu abstrahieren.

Wenn Sie keine Wertobjekte verschrotten, spricht nichts gegen eine Aktualisierung.

Answer 4

Soweit ich das verstanden habe, UserPreferenceInfo ist ein Teil von User Einheit. Ergo ist die Entität Benutzer eine Aggregatwurzel, die mit UserRepository als Ganzes, zusammen mit UserPreferenceInfo und andere Objekte.

Ich persönlich denke, dass UserPreferenceInfo ist ein Entitätstyp, da es Identität besitzt - es kann geändert, gespeichert und aus dem Repository abgerufen werden und wird immer noch als dasselbe Objekt betrachtet (d.h. es besitzt Identität). Aber das hängt von Ihrer Verwendung ab.

Es spielt IMHO keine Rolle, wie das Objekt in der DAL dargestellt wird - ist es in einer separaten Tabelle oder Teil einer anderen Tabelle gespeichert. Einer der Vorteile von DDD ist die Unkenntnis der Persistenz und das ist in der Regel eine gute Sache.

Natürlich kann ich mich irren, ich bin auch neu bei DDD.

Answer 5

Die Frage ist - was ist dieses UserPreferencesInfo-Objekt?

Ich weiß nicht, wie dieser Fall von NHibernate unterstützt wird, aber einige ORMs unterstützen spezielle Konzepte für diese Fälle. DataObjects.Net enthält zum Beispiel Strukturen Konzept. Es scheint, dass man so etwas in NH braucht.