Avoiding anemic domain model - a real example

Question

I am trying to understand Anemic Domain Models and why they are supposedly an anti-pattern.

Here is a real world example.

I have an Employee class, which has a ton of properties - name, gender, username, etc

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

Next we have a system that involves rotating incoming phone calls and website enquiries (known as 'leads') evenly amongst sales staff. This system is quite complex as it involves round-robining enquiries, checking for holidays, employee preferences etc. So this system is currently seperated out into a 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
     }
}

Then on the backside of our website enquiry form we have code like this:

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

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

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

I don't really encounter many problems with this approach, but supposedly this is something that I should run screaming from because it is an Anemic Domain Model.

But for me its not clear where the logic in the lead rotation service should go. Should it go in the lead? Should it go in the employee?

What about all the injected repositories etc that the rotation service requires - how would they be injected into the employee, given that most of the time when dealing with an employee we don't need any of these repositories?

Answer 1

I think your design is fine here. As you know, the anemic domain model anti-pattern is a backlash against the trend of avoiding any behaviour coded in domain objects. But conversely it doesn't mean all behaviour relating to a domain object must be encapsulated by that object.

As a rule of thumb, behaviour that is intrinsicly tied to the domain object and is defined entirely in terms of that one domain object instance can be included in the domain object. Otherwise, to keep responsibilities clear, it's best to put it externally in a collaborator/service like you have done.

Answer 2

In this case this doesn't constitute an Anemic Domain Model. An Anemic Domain Model is specifically about validating and transforming the objects. So an example of this would be if an external function actually changed the state of the Employees or updated their details.

what is happening in this case is you are taking all of the employees and making a selection of one of them based on their information. It is fine to have a separate object that examines others and makes decisions with regard to what it finds. It is NOT ok to have an object that is used to transition an object from one state to another.

An example of an Anemic Domain Model in your case would be to have an external method

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

that takes an Employee object and updates its hours worked for the week, making sure that flags are raised if the hours exceed a certain limit. The problem with this is that if you only have Employee objects then you have no knowledge of how to modify their hours within the correct constraints. In this case the way to deal with it would be to move the updateHours method into the Employee class. That is the crux of the Anemic Domain Model anti pattern.

Answer 3

It's all in your head - consider rotation service to be a part of the domain model and the problem dissolves.

Rotation needs to keep information about many employees, so it belongs to neither lead, nor to any single employee object. It does to deserve to be a domain object in itself.

Just renaming "RotationService" to something like "Organization.UserSupportDepartment" makes it obvious.