DDD: les sous-classes et entités racine

voix
9

Disons que je l'entité typique de voiture

class Car : Entity
{
    public double MaxSpeed { get; set; }
    public Color Color { get; set; }
    /* ... */
}

Cette entité, dans mon modèle de domaine, serait l' entité racine d'un agrégat .

Maintenant , disons que je me spécialise voitures. Je crée une Ferrari , et les heureux propriétaires de Ferrari aime les appeler par un surnom:

class Ferrari : Car
{
    public string Nickname { get; set; }
}

Disons que j'ai une autre entité, la Société entité. Il serait l' entité racine d'un autre agrégat . Il y a beaucoup de gens qui travaillent sur une société, représentée par l'entité personne . Les personnes peuvent avoir des voitures. Mais le président d'une entreprise est généralement très riche et ce genre de personnes, ils ont Ferraris:

class President : Person
{
    public Ferrari Ferrari { get; set; }
}

Dans cette situation, je l'entité Président, qui est à l' intérieur de la Aggregate Société , qui tient une référence à une Ferrari, une spécialisation de l'entité racine d'un autre agrégat.

Est - ce correct compte tenu de DDD? Puis / devrais - je envisager la spécialisation des entités racine eux - mêmes entités racine 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 voiture (puisque Ferrari est une voiture)?


Maintenant , nous allons dire que je dois persister ce modèle à une base de données . Je pense que ma question ne dépend pas du cadre OR / M je vais utiliser.

Comment dois - je construire la table contenant Cars ? Dois - je construire une seule table voitures, avec une colonne « CarType » (valeurs possibles: « Car », « Ferrari »), et une colonne Pseudo annulable?

Ou devrais-je construire une table pour les voitures et une table pour Ferraris, ce dernier ayant sa PK une FK de voitures?

Merci!

Créé 26/08/2009 à 23:42
source utilisateur
Dans d'autres langues...                            


3 réponses

voix
4

Vous ne devriez pas utiliser l'héritage pour modéliser votre domaine parce que vous allez bientôt des ennuis une fois le modèle commence à devenir complexe.

Le président est tout simplement un rôle de la personne et la personne peut avoir plusieurs rôles. Peut-être que le président a un seul rôle, mais qui est tout simplement accidentelle en choisissant mauvais exemple.

Ferrari ne devrait pas être héritée de la voiture non plus. Il est pas évident sur Ferrari par exemple, parce qu'ils ne font qu'un type de voitures, mais considèrent entreprise qui fabrique de nombreux types comme camionnettes, berlines, berlines, camions et ainsi de suite. Vous voudrez probablement faire des cours pour tous les types qui héritera de la classe de voiture. Et puis quoi ... tu vas faire cinq classes Toyota qui hériteront de chaque type? Tel que...

Car -> Sedan -> ToyotaSedan
Car -> Truck -> ToyotaTruck
Car -> Hatchback -> ToyotaHatchback

Ce serait ridicule.

Avertissement: Je ne sais rien sur les voitures. Toutefois...

Ne pas utiliser l'héritage pour le modèle de votre domaine. Déjà.

Essayez sans héritage et il est également devenu évident comment persister votre domaine.

Créé 29/08/2009 à 21:21
source utilisateur

voix
3

En général, lorsque vous traversez les frontières de la racine globale vous permettent que la référence soit de l'ID de l'autre agrégat de racine. Vous utilisez ensuite cet ID pour rechercher l'autre agrégat dans son référentiel.

Donc, dans votre cas, vous voulez Président d'avoir une pièce d'identité de voiture et si jamais vous aviez besoin de faire quelque chose à la voiture du président que vous utilisez l'ID de voiture pour aller au dépôt pour obtenir la voiture. Le président ne serait pas une référence à la voiture elle-même.

Maintenant, sur cette Ferrari. Il est un peu difficile à appliquer que dans une terminologie standard DDD. Normalement, vous mettriez une validation sur la cession d'une voiture à un président. Ou peut-être il y a un CarBuyingService juste pour les présidents qui fait que vous obtenez droite. Normalement, dans les spécialisations DDD ne sont pas eux-mêmes des agrégats de racines.

Créé 29/08/2009 à 21:23
source utilisateur

voix
2

Je pense que vous commencez à perdre beaucoup de la flexibilité du système en créant des types concrets de ces entités. Le type de relation que vous insinuez est quelque chose que je tends généralement avec une entité « Type ». Par exemple, vous avez une voiture. Une Ferrari est un type de voiture. Les deux entités qui sont à la charge de qui sont une voiture et un CarType.

La façon dont vous parlez le faire, vous devez ajouter de nouvelles entités à chaque fois est introduit un nouveau type. Si tout ce que vous essayez de capturer est le « surnom » de la voiture, je pense que c'est juste un autre morceau de données, et non une autre entité. Sauf si vous avez des données différentes (par exemple différents noms de propriété) et / ou les différences de comportement dans les entités de voitures pour différents types, vous ne gagnez pas beaucoup avec cette approche. Je préférerais avoir des méthodes comme dépôt FindCarByType () et faire face à un type d'entité, pour réduire le risque.

Je ne suis pas un expert DDD, et je me bats avec des concepts (ou plus comme aux prises avec les multiples interprétations de certains concepts). Je trouve qu'il n'y a pas une mise en œuvre pur à 100%, et qu'il ya des nuances à chaque mise en œuvre que je l'ai vu.

Modifier Follows

Je vois que je mal lu une partie de ce que vous aviez écrit. Je vois que le surnom est pas pour tous les véhicules, mais seulement pour Ferrari: Car. Je pense que la réponse est vraiment « ça dépend ». Comment la spécialisation beaucoup de domaine que vous avez dans le reste de votre modèle? Ayant un surnom peut être répandue parmi les entités Ferrari, mais est-il exclusif? Il est non seulement sur les données réelles, mais les exigences. Fondamentalement, il se résume à combien la spécialisation vous êtes attendent dans ces entités.

Créé 29/08/2009 à 20:52
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more