DDD: Kann ein Value Object haben Listen in ihnen?

Question

Ich bin nicht gut in Domain Driven Design versiert und ich habe seit kurzem ein Domain-Modell für ein Projekt erstellt. Ich habe noch nicht auf einem ORM entschieden (obwohl ich wahrscheinlich mit NHibernate gehen) und ich versuche zur Zeit, um sicherzustellen, dass mein Wert Objekte genau das sein sollten.

Ich habe ein paar VOs, die als fast kein Verhalten andere haben zu kapseln „wie“ Begriffe, zum Beispiel:

public class Referral {
    public Case Case { get; set; } // this is the a reference to the aggregate root
    public ReferralType ReferralType { get; set; } // this is an enum
    public string ReferralTypeOther { get; set; }
} // etc, etc.

Diese besondere Klasse hat einen Verweis auf „Case“, die zwei Ebene nach oben, also, wenn ich sagen eine Überweisung zugreifen wollte ich gehen könnte: case.social.referral (Fall, soziale und Referral alle Klassen sind, wird ein einzelner Sozial in einem Fall und es gibt eine einzige Überweisung innerhalb eines Social). Nun, da ich es bin auf der Suche, wie ich es geben, ich glaube nicht, dass ich einen Fall, in dem Referral benötigen, da sie zugänglich über die soziale Einheit sein werden, richtig?

Jetzt gibt es keinen Zweifel daran, dies ist etwas, das ein VO sein sollte, und die Methode, die ich plane dies in die Datenbank persistieren verwenden, um entweder NHibernate ihm eine Ersatz-Kennung zuzuweisen (was ich bin immer noch nicht zu klar auf, wenn jemand könnte bitte sorgfältig ausarbeiten, das auch würde es mir helfen, da ich weiß nicht, ob die Ersatzkennung erfordert, dass ich eine Id in meinem VO habe bereits oder wenn es ohne eine betreiben) und / oder einen geschützt Id-Eigenschaft, die außerhalb der Referral-Klasse nicht ausgesetzt werden würde (für den alleinigen Zweck der DB persistierender).

Nun zu meinem Titel Frage: Sollte ein VO eine Sammlung hat, (in meinem Fall eine List) im Innern? Ich kann nur denken, dies als eine Eins-zu-viele-Beziehung in der Datenbank, aber da gibt es keine Identität ist es nicht ausreichend erschien die Klasse eine Einheit zu machen. Unten ist der Code:

public class LivingSituation {
    private IList<AdultAtHome> AdultsAtHome { get; set; }
    public ResidingWith CurrentlyResidingWith { get; set } // this is an enum
} // etc, etc.

Diese Klasse hat derzeit keine ID und die AdultsAtHome Klasse nur Eigenart haben (String, int). So bin ich nicht sicher, ob dies ein Unternehmen sein soll oder wenn es als ein VO bleiben und ich brauche nur meine ORM zu konfigurieren, um eine 1 zu verwenden: m-Beziehung für dieses ihre eigenen Tabellen und ein eigenes / geschützt Id Feld, so dass die ORM können zur DB bestehen.

Auch soll ich gehen mit normalisierten Tabellen für jede meiner Klassen, oder nicht? Ich glaube, ich würde nur eine Tabelle pro Klasse verwenden müssen, wenn die Möglichkeit besteht, die an eine Stelle oder Wertobjekt zugeordnet mehrere Instanzen der Klasse und / oder besteht die Möglichkeit, mit einer Sammlung von 1: m-Beziehungen mit einigen dieser Objekte . Ich habe kein Problem mit einer einzigen Tabelle für bestimmte Wertobjekte verwenden, die Eigenarten haben aber mit verschachtelten Typen finde ich es von Vorteil wäre, normalisierte Tabellen zu verwenden. Irgendwelche Vorschläge auf, dies auch?

Es tut uns mit den vielfältigen Fragen so verbose:

1) Muß ich eine Ersatz-Kennung muß (mit etwa NHibernate) für meine Wertobjekte?

2) Wenn # 1 ja ist, dann ist diese Notwendigkeit, private / geschützt sein, so dass mein Wert Objekt „bleibt“ ein Wertobjekt in Konzept?

3) Kann ein Wertobjekt hat andere Wertobjekte (in etwa eine List) oder wäre die eine Einheit bilden? (Ich denke, die Antwort auf diese Frage nein ist, aber ich würde es vorziehen, um sicher zu sein, bevor ich weiter vorgehen.)

4) Muss ich einen Verweis auf das Aggregat Wurzel von einem Wert-Objekt, das ein paar Stufen nach unten aus dem Aggregat Wurzel? (Ich glaube nicht, dass ich tue, ist dies wahrscheinlich ein Versehen meinerseits, wenn das Modell zu schreiben, jemand zu?)

5) Ist es OK, normalisierte Tabellen für bestimmte Dinge zu verwenden (wie verschachtelte Typen und / oder Typen mit Sammlungen als Eigenschaften, die ihre eigenen Tabellen ohnehin für die 1 benötigen würden: m-Beziehung), während die ORM mit tun, um die Zuordnung für die einfache Wert-Objekte auf die gleiche Tabelle, die zu meiner Entität gehört?

Vielen Dank noch einmal.

Answer 1

Werfen Sie einen Blick auf den Antworten auf Fragen im Zusammenhang mit hier und hier

---

1) Ja - Wenn Sie speichern VOs in ihrer eigenen Tabelle

2) Wenn Sie eine private / protected ID-Eigenschaft verwenden können, dann groß. Alternativ können Sie die ID-Eigenschaft explizit Schnittstellen zu ‚verstecken‘ verwenden.

Aber, in Frage zu lesen, schlagen Sie vor, dass Entwickler, die eine ID-Eigenschaft sehen werden automatisch das Objekt übernehmen ist ein Unternehmen? Wenn ja, müssen sie (wieder) Training.

3) Ja, es kann, aber mit folgenden Einschränkungen:

• Es sollte ziemlich selten sein
• Es sollte nur verweisen auf andere VOs

Auch bedenken Sie: VOs nicht dableiben. Wäre es einfach / effizient sein, die gesamte VO ist jedes Mal neu erstellen es notwendig? Wenn nicht, ist es ein Entity machen.

4) Hängt davon ab, wie Sie Ihren Aggregate Locking zu implementieren. Wenn Sie Ayende Lösung , ist die Antwort ja. Andernfalls würden Sie einen Mechanismus müssen die Objektgraphen zurück in die Aggregate Wurzel zu durchqueren.

5) Ja. Vergessen Sie nicht, dass DDD ist Persistence Ignorant (in einer idealen Welt!).

---

Jedoch ...

Ich glaube, Referral sollte ein Entity sein . Stellen Sie sich diese Gespräche:

Conversation 1:

• Tom: "Hey Joe Können Sie mir David Jone Befassung!?"
• Joe: "Welche?"
• Tom: "Sorry, ich meine Referral No.123"

Conversation 2:

• Tom: "Hey Joe Können Sie mir David Jone Befassung!?"
• Joe: "Welche?"
• Tom: "Ich kümmere mich nicht - geben Sie mir irgendein"

Konversation 1 legt nahe, dass Referral ist ein Entity , während Gespräch 2 schlägt vor, es ist ein VO.

Eine weitere Sache: Ist Referral.ReferralType Änderung während es Lebensdauer ist (es gibt einen weiteren Hinweis, dass es sollte eine Entity sein)? Wenn es nicht ändern, sollten polyporphism mit und lassen Sie NH damit umgehen.

Ich hoffe, das hilft!