problème de dénomination de modélisation de domaine

Il existe certaines entités simples dans une application (par exemple contenant uniquement un identifiant et un titre) qui changent rarement et sont référencées par les entités plus complexes de l'application. Ce sont généralement des entités telles que Country, City, Language etc.problème de dénomination de modélisation de domaine

Comment sont-ils appelés? Je l'ai utilisé les noms suivants pour ceux dans le passé, mais je ne suis pas sûr de la meilleure façon de les appeler:

données de référence
valeurs recherche
dictionnaires

grâce

Source

2010-06-02 cherouvim

Je dirais que les données de référence

Voir link text

Source

2010-06-02 06:28:18 djna

Merci. Toute référence/documentation à ce sujet? – cherouvim

Données de référence c'est alors. Merci – cherouvim

Vous avez tagué avec "ddd", donc en supposant que vous cherchez une approche plus axée sur le domaine de la conception, déposez l'identifiant sur ces objets et traitez-les comme Value Objects.

La raison pour laquelle vous pourriez envisager de supprimer l'identificateur est qu'il ajoute une complexité inutile au domaine de problème. Par exemple, vous avez une table "Pays" dans votre implémentation, je suppose? Vous l'auriez toujours, mais ce ne serait pas une recherche référentielle. Vous l'utiliseriez uniquement comme "données de référence". Chargez-le d'abord pour les scénarios où il doit être référencé - peut-être que votre interface utilisateur le lie à une liste déroulante, par exemple ...

Lorsque l'entité est enregistrée ou mise à jour, vous stockez la valeur de l'objet, d'où le "valeur" "objet". Si l'utilisateur change l'entité pour une autre valeur, pas de problème, il suffit de mettre à jour la valeur. C'est une recherche associative de moins qui doit être faite lors des opérations CRUD, ce qui rend le modèle global moins complexe.

Source

2010-06-02 19:12:27

Merci. Oui, j'ai lu sur les objets de valeur dans http://amzn.com/0321125215. C'est un concept intéressant, mais dans un niveau de DB ne ressemble-t-il pas à la dénormalisation? Les littéraux du pays seront dispersés partout. Plus important encore, quand j'ai besoin de changer un texte de pays (par exemple une faute de frappe), je devrais scanner de nombreuses tables pour appliquer le correctif. – cherouvim

@cherouvim - L'une des clés de DDD est que la base de données n'a pas d'importance, tant que vous disposez d'une couche de mappage fiable entre vos entités et vos données. En ce qui concerne les fautes de frappe, vous avez raison. Vous devriez chercher plusieurs endroits pour faire une correction. Du point de vue de la gestion, vous pouvez toujours conserver une procédure stockée pour mettre à jour chaque instance. Par exemple, vous pouvez avoir un proc stocké pour mettre à jour toutes les références de votre pays qui prend l'ancienne et la nouvelle valeur en paramètres et exécute les instructions de mise à jour pour vous, vous n'avez donc qu'à appeler un proc pour le réparer. –

(suite) Cependant, on peut dire que devoir changer des valeurs existantes est vraiment un cas limite. La fréquence à laquelle vous auriez besoin de le faire serait très faible et, puisque ces données sont assez statiques, vous devriez avoir ce genre de problèmes triés avant que votre code ne devienne "qualité de production". Le livre auquel vous faites référence est la "Bible Bleue" - au même endroit que la définition sur le lien que j'ai fourni. :-) –

problème de dénomination de modélisation de domaine

Répondre

Questions connexes