mettre la logique complexe, multi-domaine: dans la couche Service ou dans le modèle lui-même?

Question

Je voudrais appliquer les principes de conception guidée par les domaines dans mon projet, mais je ne pouvais pas déterminer ce que je devais faire avec la logique métier des modèles dépendants.

Par exemple, supposons que ce scénario:
je Person et Car modèles de domaine. Chaque personne est apte à acheter certaines voitures de db en fonction de l'âge/budget/préférences/etc. Dans mon modèle, je voudrais avoir une liste de voitures (SuitableCars) qui sont appropriées pour cette personne.

public class Person 
{ 
    public List<Car> SuitableCars {get; set;} 
} 

Mais afin de le faire en ce moment, je dois appeler une méthode de service (GetSuitableCarsForPerson) pour extraire des données de db (DI avec dépôt), exécutez mon (parfois assez complexe dépendant de plusieurs modèles) une logique personnalisée et obtenir les voitures.

public class PersonService : IPersonService 
{ 
    private IRepository _repo; 

    public PersonService(IPRepository repository) 
    { 
     _repo = repository; 
    } 

    public List<Car> GetSuitableCarsForPerson(Person person) 
    { 
     // business goes here right now. 
    } 

} 

Ainsi, la déclaration de SuitableCars propriété deviendra:

private IPersonService _personService; 
public List<Car> SuitableCars 
{ 
    get 
    { 
     // I have to inject a PersonService in my model. Bad practice? 
     return _personService.GetSuitableCarsForPerson(this); 
    } 
} 

AFAIK, les services devraient être conservés mince (ref) et sont utilisés pour vous permettre de placer les entreprises non-DomainModel liés à eux. Mais je crois que la logique comme celle que j'ai décrite appartient au modèle lui-même. Alors, comment gérer ces types de logiques où je devrais accéder à des modèles pertinents et faire divers validations/filtres personnalisés pour obtenir les données appropriées?
Merci.

Answer 1

Il semble que la définition de l'ensemble des voitures appropriées pour une personne dépend de facteurs en dehors du modèle de la personne et peut varier indépendamment de la personne. L'ensemble des voitures appropriées dépend non seulement des préférences de la personne mais aussi de l'ensemble des voitures. L'ensemble des voitures varie indépendamment de la personne et ainsi l'ensemble des voitures appropriées pour une personne donnée est une cache d'une opération qui détermine l'ensemble des voitures appropriées. Ces observations indiquent qu'un référentiel ou un service de domaine doit renvoyer des ensembles de voitures adaptées à une personne et que l'association entre une personne et l'ensemble des voitures appropriées ne doit pas être exprimée directement sur le modèle de personne. Ce qui pourrait être une association appropriée pour exprimer directement sur le modèle de personne est l'ensemble de voitures que cette personne a spécifié comme modèles préférés parce que dans ce cas la personne est le «propriétaire» de ces données. En DDD, il est acceptable d'exprimer des associations directement dans des modèles ou par l'utilisation de référentiels et le choix d'une approche spécifique dépend de plusieurs facteurs, dont certains sont décrits ci-dessus. Jetez un oeil à this series of articles pour un traitement en profondeur de la façon de concevoir vos modèles.

Answer 2

Espérons que cette réponse https://stackoverflow.com/a/1209765/145595 offrira quelques conseils sur la façon de procéder.