Избегая модели анемии домена - реальный пример

Question

Я пытаюсь понять модели анемичных домен и почему они предположительно являются анти-образцом.

Вот пример реального мира.

У меня есть класс сотрудника, который имеет тонну свойств - имя, пол, имя пользователя и т. Д.

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

Затем у нас есть система, которая включает в себя вращающиеся входящие телефонные звонки и запросы на веб-сайт (известные как «заявки») равномерно среди персонала продаж. Эта система довольно сложная, поскольку она включает в себя круглые добивные запросы, проверку на наличие праздников, предпочтения сотрудников и т. Д., Итак, эта система в настоящее время отделена на сервис: сотрудничество.

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
     }
}

Затем на задней стороне нашей формы запроса веб-сайта у нас есть код, как это:

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

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

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

Я не очень сталкиваюсь с множеством проблем с этим подходом, но предположительно это то, что я должен бегать кричать из, потому что это Модель анемии домена.

Но для меня это неясно, где логика в ведущей службе вращения должна идти. Должно ли это идти в лидерстве? Должен ли он идти на сотрудника?

Как насчет всех введенных репозиториев и т. Д., Для того, что требует службы вращения - как они будут вводиться в сотрудника, учитывая, что большую часть времени при работе с работником нам не нужна никаких из этих репозиторов?

Answer 1

В этом случае это не представляет собой модель анемии домена. Модель анемии домена специально о проверке и преобразовании объектов. Отказ Таким образом, пример этого будет, если внешняя функция фактически изменила состояние сотрудников или обновила свои данные.

То, что происходит в этом случае, вы принимаете всех сотрудников и выбираете один из них на основе их информации. Хорошо иметь отдельный объект, который исследует другие и принимает решения в отношении того, что он находит. Не в порядке иметь объект, который используется для перехода объекта из одного состояния в другое.

Пример модели анемии в вашем случае будет иметь внешний метод

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

Это требует объекта сотрудника и обновления его часов работало на неделю, убедившись, что флаги повышаются, если часы превышают определенный предел. Проблема с этим заключается в том, что если у вас есть только объекты сотрудников, то у вас нет знаний о том, как изменять свои часы в правильных ограничениях. В этом случае способ справиться со своим методом обновленийHours в класс сотрудника. Это суть анемической доменной модели Anti Pattern.

Answer 2

Я думаю, что ваш дизайн здесь хорошо. Как вы знаете, анемичная модель домена анти-модели - это реакция против тенденции избежать любого поведения, закодированного в доменных объектах. Но наоборот это не значит все Поведение, относящееся к объекту домена, должны быть инкапсулированы этим объектом.

Как правило, поведение, которое, привязанное к объекту домена и полностью определяется с точки зрения того, что один экземпляр объекта домена может быть включен в объект домена. В противном случае, чтобы сохранить обязанности ясным, лучше поставить его снаружи в сотрудничестве / услуге, как вы сделали.

Answer 3

Это все в вашей голове - рассмотреть вопрос о вращении, чтобы стать частью модели домена, а проблема растворяется.

Вращение должно сохранять информацию о многих сотрудниках, поэтому она не принадлежит ни лиму, ни на одного объекта одного сотрудника. Это заслуживает того, чтобы быть доменным объектом сам по себе.

Просто переименование «Rotationservice» к чему-то вроде «Организация. УЗвысопопурта» делает его очевидным.

Answer 4

Если ваша модель домена содержит только роли и вещи, а не мероприятия как поведение, то это анемично. Тем не менее, я говорю о поведении в отношении модель не объект. Отказ Я говорю о разнице между ними в другом ответе ... https://stackoverflow.com/a/31780937/116442.

С вашего вопроса вы разбите мои первые два правила моделирования анализа доменов: -

1. Поведение, смоделированное как (записанные) действия, находится в основе модели домена. Добавьте их первым.
2. Модель доменных действий как классы, а не методы.

Я бы добавил вопрос «запрос» к модели. С ним модель имеет поведение и может объединяться и работать в группе объектов без внешнего контроллера или скрипта.