anemic-domain-model - 避免贫血域模型 - 一个真实的例子

Question

我正在尝试理解贫血领域模型以及为什么它们被认为是反模式。

这是一个现实世界的例子。

我有一个 Employee 类，它有大量属性 - 姓名、性别、用户名等

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

接下来，我们有一个系统，该系统涉及在销售人员之间均匀轮流来电和网站查询(称为“潜在客户”)。该系统非常复杂，因为它涉及循环查询、检查假期、员工偏好等。因此该系统目前被分成一个服务: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
     }
}

然后在我们网站查询表格的背面我们有这样的代码:

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

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

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

我并没有真正遇到这种方法的很多问题，但据推测这是我应该尖叫的事情，因为它是一个贫血领域模型。

但对我来说，不清楚领先轮换服务中的逻辑应该去哪里。它应该领先吗？它应该放在员工身上吗？

轮换服务所需的所有注入(inject)存储库等怎么样 - 鉴于大多数时候我们在与员工打交道时不需要任何这些存储库，那么如何将它们注入(inject)到员工中？

Answer 1

在这种情况下，这并不构成贫血领域模型。贫血域模型是 specifically about validating and transforming the objects 。因此，一个例子是外部函数实际上更改了员工的状态或更新了他们的详细信息。

在这种情况下发生的情况是，您正在收集所有员工，并根据他们的信息选择其中一名员工。拥有一个单独的对象来检查其他对象并根据其发现的内容做出决定是很好的。拥有一个用于将对象从一种状态转换到另一种状态的对象是不行的。

您的案例中贫血域模型的一个示例是使用外部方法

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

它采用 Employee 对象并更新其本周的工作时间，确保在工作时间超过特定限制时引发标志。这样做的问题是，如果您只有 Employee 对象，那么您不知道如何在正确的约束内修改他们的工作时间。在这种情况下，处理方法是将 updateHours 方法移至 Employee 类中。这就是贫血领域模型反模式的关键。