Question

Je ne suis pas très familiarisé avec la conception pilotée par domaine et j'ai récemment commencé à créer un modèle de domaine pour un projet. Je n'ai toujours pas choisi d'ORM (bien que j'irais probablement avec NHibernate) et j'essaie actuellement de faire en sorte que mes objets de valeur soient exactement ce que c'est.

J'ai quelques objets virtuels qui n'ont presque aucun comportement autre que celui d'encapsuler "comme". termes, par exemple:

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.

Cette classe particulière fait référence à " Case " ce qui est deux niveaux plus haut, donc si je disais que j'allais accéder à une référence, je pourrais aller: case.social.referral (Case, Social et Referral sont toutes des classes, il y a une seule sociale dans une affaire et il y a une unique référence dans un social). Maintenant que je le regarde au fur et à mesure que je le tape, je ne pense pas avoir besoin d'un cas dans le renvoi, car il sera accessible via l'entité sociale, n'est-ce pas?

Maintenant, il ne fait aucun doute dans mon esprit que c'est quelque chose qui devrait être une VO, et la méthode que je compte utiliser pour la conserver dans la base de données consiste à ce que NHibernate lui attribue un identifiant de substitution (que je ne suis toujours pas trop clair sur, si quelqu'un pouvait s'il vous plaît élaborer sur cela aussi cela m'aiderait, puisque je ne sais pas si l'identifiant de substitution exige que j'ai déjà un Id dans mon VO ou s'il peut fonctionner sans un) et / ou un Propriété Id protégée qui ne serait pas exposée en dehors de la classe Referral (dans le seul but de persister dans la base de données).

Passons maintenant à la question de titre: une VO doit-elle contenir une collection (dans mon cas, une liste)? Je ne peux penser à cela que comme une relation un-à-plusieurs dans la base de données, mais comme il n'y a pas d'identité, cela ne semblait pas suffisant pour faire de la classe une entité. Ci-dessous le code:

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

Cette classe n'a actuellement pas d'identifiant et la classe AdultsAtHome a juste des types intrinsèques (string, int). Donc, je ne suis pas sûr si cela doit être une entité ou si elle peut rester en tant que VO et je dois juste configurer mon ORM pour utiliser une relation 1: m pour cela en utilisant leurs propres tables et un champ ID privé / protégé afin que le ORM peut persister dans la base de données.

Aussi, devrais-je utiliser des tables normalisées pour chacune de mes classes ou pas? Je pense que je n'aurais besoin d'utiliser une table par classe que s'il est possible que plusieurs instances de la classe soient affectées à une entité ou à un objet de valeur et / ou qu'il existe la possibilité d'avoir des collections 1: m relations avec certains de ces objets. . Je n'ai aucun problème à utiliser une seule table pour certains objets de valeur qui ont des types intrinsèques mais avec des types imbriqués, je pense qu'il serait avantageux d'utiliser des tables normalisées. Des suggestions à ce sujet également?

Désolé d'être si bavard avec les multiples questions:

1) Ai-je besoin d'un identifiant de substitution (avec par exemple NHibernate) pour mes objets de valeur?

2) Si n ° 1 est oui, cette propriété doit-elle être privée / protégée pour que mon objet de valeur "reste" " un objet de valeur dans le concept?

3) Un objet de valeur peut-il avoir d'autres objets de valeur (une liste, par exemple) ou constituerait-il une entité? (Je pense que la réponse à cette question est non, mais je préférerais être sûr avant de continuer.)

4) Ai-je besoin d'une référence à la racine agrégée à partir d'un objet de valeur situé à quelques niveaux de la racine agrégée? (Je ne pense pas que je le sache, c'est probablement un oubli de ma part lorsque j'écris le modèle, tout le monde est d'accord?)

5) Est-il correct d’utiliser des tables normalisées pour certaines choses (comme les types imbriqués et / ou les types avec des collections en tant que propriétés qui nécessiteraient quand même leurs propres tables pour la relation 1: m) tout en laissant l’ORM faire le mappage pour objets de valeur plus simples à la même table qui appartient à mon entité?

Merci encore.

Était-ce utile?

La solution

Consultez les réponses aux questions connexes ici et ici

1) Oui - Si vous stockez des VO dans leur propre table

2) Si vous pouvez utiliser une propriété d'identifiant privé / protégé, alors tant mieux. Vous pouvez également utiliser des interfaces explicites pour "masquer" la propriété ID.

Mais, en lisant votre question, suggérez-vous que les développeurs qui voient une propriété d'ID supposent automatiquement que l'objet est une entité? Si oui, ils ont besoin de (re) formation.

3) Oui, vous le pouvez, mais avec les restrictions suivantes:

  • Cela devrait être assez rare
  • Il devrait uniquement faire référence à d'autres VO

Pensez également à ceci: les VO ne devraient pas rester dans les parages. Serait-il facile / efficace de recréer la VO au complet à chaque fois que cela est nécessaire? Sinon, faites-en une entité.

4) dépend de la manière dont vous souhaitez mettre en œuvre votre verrouillage global . Si vous souhaitez utiliser La solution d'Ayende , la réponse est oui. Sinon, vous aurez besoin d’un mécanisme pour repasser le graphe d’objet vers la racine d’agrégat.

5) Oui. N'oubliez pas que DDD est Ignorant de la persistance (dans un monde idéal!).

Cependant ...

Je pense que le renvoi doit être une entité . Imaginez ces conversations:

Conversation 1:

  • Tom: "Hey Joe! Pouvez-vous me donner la référence de David Jone? & Quot;
  • Joe: "Lequel?"
  • Tom: "Désolé, je parle du renvoi n ° 122"
  • .

Conversation 2:

  • Tom: "Hey Joe! Pouvez-vous me donner la référence de David Jone? & Quot;
  • Joe: "Lequel?"
  • Tom: "Je m'en fous - donnez-moi simplement n'importe quel"

La conversation 1 suggère que le renvoi est une entité , tandis que la conversation 2 suggère qu'il s'agit d'une VO.

Encore une chose: Referral.ReferralType change-t-il au cours de sa durée de vie (il y a un autre indice que ce devrait être une entité)? Si cela ne change pas , envisagez l’utilisation du polyporphisme et laissez NH le gérer.

J'espère que ça aide!

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top