Disons que j'ai l'entité typique Cette entité, dans mon modèle de domaine, serait la Disons que je spécialise des voitures. Je crée un Ferrari et les propriétaires heureux de Ferraris aiment les appeler par un surnom: disons que j'ai une autre entité, le < Strong> compagnie entité. Ce serait l'entité racine est-ce correct en vue de DDD? peut / dois-je envisager la spécialisation des entités racines elles-mêmes comme des entités racines du même agrégat? Je veux dire, dans le domaine que j'ai décrit, est l'entité Ferrari également l'entité racine de l'agrégat de la voiture (puisque Ferrari est également une voiture)? Disons que je dois Comment devrais-je construire la table ou devrais-je construire une table pour les voitures et un Table pour Ferraris, ce dernier ayant son PK Un FK de voitures? Merci!
3 Réponses :
Je pense que vous commencez à perdre beaucoup de flexibilité du système en créant des types concrets de ces entités. Le type de relation que vous impliquez est quelque chose que j'ai généralement la main avec une entité "type". Par exemple, vous avez une voiture. Une Ferrari est un type de voiture. Les deux entités qui sont supportées de cela sont une voiture et un cartype.
La façon dont vous parlez de le faire, vous devrez ajouter de nouvelles entités à chaque fois qu'un nouveau type est introduit. Si tout ce que vous essayez de capturer est le "surnom" de la voiture, je penserais que c'est juste un autre morceau de données, et non une autre entité. Sauf si vous avez des données différentes (c'est-à-dire différents noms de propriété) et / ou des différences de comportement dans des entités de voitures pour différents types, vous ne gagnez pas grand chose avec cette approche. Je préférerais avoir des méthodes de référentiel comme FindCarbyType () et traiter avec un type d'entité pour réduire les risques.
Je ne suis en aucun cas un expert DDD, et je me débats avec des concepts (ou plus comme des difficultés avec les multiples interprétations de certains concepts). Je constate qu'il n'y a pas une mise en œuvre 100% pure et qu'il y a des nuances à chaque mise en œuvre que j'ai vue.
Je vois que j'ai mal interprété une partie de ce que vous aviez écrit. Je vois que le surnom n'est pas pour tous les véhicules, mais juste pour Ferrari: voiture. Je pense que la réponse est vraiment "cela dépend". Combien de spécialisation de domaine avez-vous dans le reste de votre modèle? Avoir un surnom pourrait être répandu parmi les entités de Ferrari, mais est-ce exclusive? Ce n'est pas seulement sur les données réelles, mais les exigences. Fondamentalement, cela revient à la quantité de spécialisation que vous attendez dans ces entités.
Fantastique! Merci! En fait, dans mon "véritable" système, "voitures" sont très importants, mais la "Ferrari" est la chose la plus importante de mon domaine, que je ne peux pas perdre une trace de, je dois faire des statistiques dessus.
Vous ne devez pas utiliser l'héritage pour modéliser votre domaine car vous aurez bientôt courir en difficulté une fois que le modèle commence à devenir complexe.
Le président est simplement un rôle de la personne et de la personne peut avoir plusieurs rôles. Peut-être que le président n'a eu qu'un seul rôle, mais c'est simplement accidentel en choisissant un mauvais exemple.
Ferrari ne devrait pas être hérité de voiture non plus. Il n'est pas évident sur l'exemple de Ferrari, car ils ne font qu'un type de voitures, mais considèrent la société de nombreux types comme des fourgonnettes, des berlines, des hayon, des camions, etc. Vous voudrez probablement faire des cours pour chaque type qui hériter d'une classe de voiture. Et puis quoi ... allez-vous faire cinq classes Toyota qui hériter de chaque type? Tels que ... ce serait ridicule. Disclaimer: Je ne sais rien sur les voitures. Cependant ... Ne pas utiliser l'héritage pour modéliser votre domaine. Jamais. Essayez-le sans héritage et il deviendra également évident comment persister votre domaine.
Merci, Lubos. Mais dans ce cas, dans mon "vrai" domaine, je avez "voitures", et il y a des voitures "génériques" et 2 types de voitures spéciales, "Ferrari" et "Porsche" qui doivent être suivis bas, bien qu'ils soient essentiellement des "voitures".
toujours, éviter l'héritage. Même si vous ne le faites pas, vous devrez en une ou deux ans, car votre modèle sera probablement plus compliqué à l'avenir de capturer de nouvelles exigences et l'héritage entraînera beaucoup de douleur dans votre conception. Des exemples de manuels à expliquer l'héritage comme le chat et le chien sont à la fois des animaux et du cercle et de la place sont des formes erronées, ce qui donne une mauvaise impression, quelle est la héritage et les programmeurs abusent souvent ce puissant concept de modélisation de domaines de modélisation. En savoir plus ici: Geocities.com/tablizer/oopbad.htm#vereng ( Je ne suis pas l'auteur)
En règle générale lorsque vous traversez les limites d'agrégat racine, vous ne permettez que la référence de l'ID de l'autre agrégat racinaire. Vous utilisez ensuite cet identifiant pour rechercher l'autre agrégat dans son référentiel.
Donc, dans votre cas, vous voudriez que le président ait une pièce d'identité de voiture et si vous avez besoin de faire quelque chose à la voiture du président, vous utiliseriez l'ID de voiture pour accéder au référentiel pour obtenir la voiture. Le président n'aurait pas de référence à la voiture elle-même.
maintenant à propos de cette Ferrari. Il est un peu difficile d'appliquer cela dans la terminologie standard DDD. Normalement, vous mettriez une certaine validation sur l'attribution d'une voiture à un président. Ou peut-être qu'il y a un carbuyingService juste pour les présidents qui vous garantit bien. Normalement dans les spécialisations DDD ne sont pas eux-mêmes des agrégats de racine.
Vous êtes le seul à avoir répondu à la question