'Pays': Objet ou entité de valeur dans DDD?
opinions de toute façon appréciée.
et, où stocker la table des noms / codes de pays? DB? Xml? Dans une classe?
merci!
3 Réponses :
Si votre domaine est géographique ou politique, il pourrait s'agir d'une entité, mais dans le cas moyen, un pays n'est qu'une valeur associée à des adresses telles que des adresses. Dans ce cas, dans le contexte de votre modèle d'objet, c'est juste une valeur.
En ce qui concerne le stockage, le modèle de domaine ne se soucie pas vraiment. Vous pouvez utiliser la base de données s'il est pratique, XML si vous préférez et une classe si vous avez un comportement associé à des pays.
Eh bien, je suis super tard, mais comment proposez-vous un objet de valeur à être «stocké»? Je suppose qu'un référentiel est hors de question, statique dans les valeurs de mémoire peut-être?
Un objet de valeur ne sera pas une racine globale, de sorte que cela n'aura pas besoin de son propre référentiel. Si vous utilisez un orj, un objet de valeur peut être mappé sur des champs composés dans une table sous une racine agrégée parent, voire, dans certaines circonstances, des tables distinctes dans lesquelles la seule identité significative est celle de l'objet propriétaire.
J'ai le même dilemme. Dans mon cas, j'utilise le pays dans le cadre du champ d'adresse. Mais j'ai un rapport où je dois apporter une liste déroulante des pays. Le rapport montre aux clients du pays sélectionné sur la base du pays de l'adresse. Je crois en ce pays d'affaires devrait être une entité. Ai-je raison?
@Devanalyste Je dirais que cela dépend de si vous avez 1) beaucoup de métadonnées sur le pays que vous devez également traiter dans votre domaine et 2) combien de comportement est associé à un "pays". Si c'est juste une chose que vous triez et filtrez, je ne suis pas sûr que ce soit un argument fort pour une entité (je trie, filtrer et agréger les valeurs contraignantes qui ne sont pas elles-mêmes des entités assez souvent). Mais si vous avez d'autres raisons de le faire, cela ne comporte pas seulement des valeurs contraignantes ou de pivoter, ou si vous trouvez cela simplifie la logique de votre domaine, il peut y avoir une justification pour cela.
Une des caractéristiques d'une entité est qu'elle a un cycle de vie, c'est-à-dire qu'il change avec le temps. Un objet de valeur ne le fait pas. En fait, les objets de valeur devraient être immuables. Donc, la question de se poser est: «L'objet de pays change-t-il au fil du temps?»
Un autre aspect qui différencie les entités et les objets de valeur est que deux objets de valeur avec les mêmes propriétés Les entités, d'autre part, sont distinctes même si elles ont les mêmes propriétés. Un client avec le nom "John Smith" peut ne pas être identique à un autre client avec le nom "John Smith".
Ainsi, compte tenu de ces caractéristiques, vous devriez pouvoir décider. Comme il ne peut y avoir qu'une seule "France" et cela ne change pas au fil du temps, c'est probablement un objet de valeur - à moins que votre application n'a besoin de suivre davantage sur un pays susceptible de changer avec le temps.
La France est déjà à la version 5.0: en.wikipedia.org/wiki/french_fifth_republic ;)
Imagine:
Vous avez une autre entité - client.
Entité client Références Objet de pays.
Vous avez 2 cas d'entité avec des objets de pays remplis de même valeur (c'est-à-dire «France»)
Vous supprimez l'objet de pays à partir de la première entité (ou d'un premier objet d'entité)