Éviter le modèle de domaine anémique - un exemple réel

Question

Je suis en train de comprendre des modèles Anemic domaine et pourquoi ils sont censés être un anti-modèle.

Voici un exemple du monde réel.

J'ai une classe d'employés, ce qui a une tonne de propriétés - nom, sexe, nom d'utilisateur, etc

public class Employee
{
    public string Name { get; set; }
    public string Gender { get; set; }
    public string Username { get; set; }
    // Etc.. mostly getters and setters
}

Ensuite, nous avons un système qui implique la rotation des appels téléphoniques entrants et les demandes de site Web (connu sous le nom « conduit ») de façon uniforme au sein du personnel de vente. Ce système est assez complexe car elle implique des enquêtes tour-robining, vérification des vacances, les préférences des employés, etc. Donc, ce système est actuellement séparé en dehors d'un service. EmployeeLeadRotationService

public class EmployeeLeadRotationService : IEmployeeLeadRotationService
{
     private IEmployeeRepository _employeeRepository;
     // ...plus lots of other injected repositories and services

     public void SelectEmployee(ILead lead)
     {
         // Etc. lots of complex logic
     }
}

Ensuite, à l'arrière de notre formulaire de demande de site Web, nous avons le code comme ceci:

public void SubmitForm()
{
    var lead = CreateLeadFromFormInput();

    var selectedEmployee = Kernel.Get<IEmployeeLeadRotationService>()
                                 .SelectEmployee(lead);

    Response.Write(employee.Name + " will handle your enquiry. Thanks.");
}

Je ne suis pas vraiment rencontrer de nombreux problèmes avec cette approche, mais ce soi-disant est quelque chose que je devrais courir crier de car il est un Anemic modèle de domaine .

Mais pour moi ce ne est pas clair où la logique au service de rotation principal devrait aller. Faut-il aller en tête? Faut-il aller dans l'employé?

Qu'en est-il tous les dépôts injectés etc que le service de rotation exige - comment seraient-ils injectés dans l'employé, étant donné que la plupart du temps en traitant avec un employé nous n'a besoin d'aucun de ces dépôts

Answer 1

Dans ce cas, cela ne constitue pas un modèle de domaine anémiques. Un Anemic modèle de domaine est spécifiquement sur la validation et la transformation des objets . Ainsi, un exemple de ceci serait si une fonction externe réellement changé l'état des employés ou mis à jour leurs coordonnées.

ce qui se passe dans ce cas est que vous prenez tous les employés et faire une sélection d'un d'entre eux en fonction de leur information. Il est bien d'avoir un objet distinct qui examine les autres et prend des décisions à l'égard de ce qu'il trouve. Il n'est pas correct d'avoir un objet qui est utilisé pour passer un objet d'un état à l'autre.

Un exemple d'un modèle de domaine anémiques dans votre cas serait d'avoir une méthode externe

updateHours(Employee emp) // updates the working hours for the employee

qui prend un objet employé et met à jour ses heures travaillées pour la semaine, en vous assurant que les drapeaux sont augmentés si les heures dépassent une certaine limite. Le problème est que si vous avez seulement employé des objets alors vous avez aucune connaissance de la façon de modifier leurs heures dans les limites correctes. Dans ce cas, la façon de traiter avec elle serait de déplacer la méthode updateHours dans la classe des employés. Tel est le point crucial du modèle de lutte contre modèle de domaine anémiques.

Answer 2

Je pense que votre conception est bien ici. Comme vous le savez, le modèle de domaine anémique anti-modèle est une réaction contre la tendance d'éviter tout comportement codé dans les objets de domaine. Mais à l'inverse, cela ne signifie pas tous comportement relatif à un objet de domaine doit être encapsulées par cet objet.

En règle générale, le comportement qui est intrinsicly lié à l'objet de domaine et est défini entièrement en termes de ce domaine un exemple d'objet peut être inclus dans l'objet de domaine. Dans le cas contraire, de garder des responsabilités claires, il est préférable de le mettre à l'extérieur dans un collaborateur / service comme vous l'avez fait.

Answer 3

Il est dans votre tête -. Considèrent que le service de rotation à une partie du modèle de domaine et le dissolve problème

La rotation doit conserver des informations sur de nombreux employés, il appartient à mener, ni à un seul objet employé. Il fait pour mériter d'être un objet de domaine en soi.

Il suffit de renommer "RotationService" à quelque chose comme "Organization.UserSupportDepartment" fait évident.

Answer 4

Si votre modèle de domaine ne contient que des rôles et des choses, et non pas les activités que le comportement, il est anémique. Cependant, je parle de comportement en ce qui concerne un modèle pas objet . Je parle de la différence entre eux dans une autre réponse ... https://stackoverflow.com/a/31780937/116442

De votre question, vous briser mes deux premières règles de modélisation d'analyse de domaine: -

1. Comportement modélisé comme (enregistrés), les activités sont au cœur d'un modèle de domaine. Ajoutez-première.
2. activités de domaine modèle comme les classes, pas des méthodes.

J'ajouterait une activité « enquête » au modèle. Avec elle, le modèle a un comportement, et peut combiner et travailler comme groupe d'objets sans un contrôleur externe ou d'un script.