Domain Driven Design - Interfaces pour la définition des rôles

Question

Je suis actuellement en train de développer un modèle de domaine pour une nouvelle application et j'ai atteint le stade où j'ai besoin de définir des relations avec des classes de types différents pouvant jouer le même rôle, et je suis confus quant à la meilleure façon de définir la relation.

Par exemple:

public class Car 
{ 
    public IDriver driver { get; set;} 
    public IPassenger passenger { get; set; } 
} 

public class Person : IDriver, IPassenger 
{ 
} 

public class Pet : IPassenger 
{ 
} 

Dans ce cas, je veux être en mesure de définir qu'un plongeur d'une voiture peut être une classe qui implémente Idriver et tout passager doit mettre en œuvre IPassenger. Dans le cas d'un passager, il pourrait s'agir d'une personne ou d'un animal de compagnie. Les interfaces définissent essentiellement les rôles de chaque classe. Ce que je veux comprendre, c'est si dans les opinions des gens c'est une bonne approche, ou si la même chose pourrait être accomplie en utilisant un mécanisme différent.

Answer 1

Difficile à dire avec les informations affichées dans la question ...

Démarrer avec le comportement, un test d'acceptation ou d'un scénario d'utilisation. (Je ne veux pas créer de scénario à partir d'air raréfié.)

Les rôles sont des relations entre objets collaborants. par exemple. L'objet B peut être une dépendance, un écouteur ou une stratégie/stratégie de l'objet A.

Vous devez maintenant concevoir du point de vue de l'objet A, c'est-à-dire Outside-in. par exemple. Qu'est-ce que Car attend de son conducteur? Ces comportements se traduiraient par des membres du rôle de pilote.