避免贫血领域模型——一个真实的例子

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

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

我有一个 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.");
}

这种方法实际上并没有遇到太多问题，但据推测，这是我应该尖叫着逃离的东西，因为它是一个 贫血领域模型。

但对我来说，领导轮换服务的逻辑应该去哪里还不清楚。它应该领先吗？应该放进员工体内吗？

轮换服务需要的所有注入的存储库等等怎么办? 考虑到大多数时候我们不需要这些存储库，如何将它们注入到员工中？