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

Das erste Mal, dass ich in einem Blog schreibe. Ich hoffe, ich mache es richtig.

Wie auch immer, da Sie uns das UserPreferencesInfo-Objekt nicht gezeigt haben, bin ich mir nicht sicher, wie es aufgebaut ist, so dass Sie eine variable Anzahl von Dingen in ihm haben können.

Wenn ich es wäre, würde ich eine einzelne Klasse namens UserPreference erstellen, mit id, userid, key, value, displaytype und allen anderen Feldern, die Sie darin benötigen. Dies ist eine Entität. Sie hat eine id und ist an einen bestimmten Benutzer gebunden.

Dann in Ihrem Benutzer Entität (die Root ich nehme an), haben eine ISet.

Answer 2

100 Immobilien klingt nach viel.

Versuchen Sie zu brechen UserPreferenceInfo in kleinere (kohärentere) Typen aufzuteilen, die wahrscheinlich/hoffentlich als VOs verwaltbar sind.