Evitando o modelo de domínio anêmico - um exemplo real

Question

Estou tentando entender os modelos de domínio anêmico e por que eles são supostamente um anti-padronização.

Aqui está um exemplo do mundo real.

Eu tenho uma aula de funcionários, que tem uma tonelada de propriedades - nome, gênero, nome de usuário, etc

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

Em seguida, temos um sistema que envolve ligações telefônicas de entrada e consultas de site (conhecidas como 'leads') uniformemente entre a equipe de vendas. Esse sistema é bastante complexo, pois envolve consultas robinitas, verificando feriados, preferências dos funcionários, etc. Portanto, este sistema é atualmente separado em um serviço: EmployeeEnToTationservice.

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

Então, na parte traseira do nosso formulário de consulta do site, temos código como este:

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

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

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

Eu realmente não encontro muitos problemas com essa abordagem, mas supostamente isso é algo que eu deveria correr gritando porque é um Modelo de domínio anêmico.

Mas para mim não está claro para onde a lógica no serviço de rotação de chumbo deve ir. Deveria ir na liderança? Deveria ir para o funcionário?

E todos os repositórios injetados, etc., que o serviço de rotação exige - como eles seriam injetados no funcionário, dado que na maioria das vezes ao lidar com um funcionário que não precisamos de nenhum desses repositórios?

Answer 1

Nesse caso, isso não constitui um modelo de domínio anêmico. Um modelo de domínio anêmico é especificamente sobre validar e transformar os objetos. Portanto, um exemplo disso seria se uma função externa realmente mudasse o estado dos funcionários ou atualizasse seus detalhes.

O que está acontecendo neste caso é que você está levando todos os funcionários e fazendo uma seleção de um deles com base em suas informações. É bom ter um objeto separado que examine os outros e toma decisões em relação ao que encontra. Não é bom ter um objeto usado para fazer a transição de um objeto de um estado para outro.

Um exemplo de modelo de domínio anêmico no seu caso seria ter um método externo

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

Isso leva um objeto de funcionários e atualiza suas horas trabalhadas durante a semana, certificando -se de que os sinalizadores sejam levantados se as horas excedem um determinado limite. O problema é que, se você tiver apenas objetos de funcionários, não terá conhecimento de como modificar suas horas dentro das restrições corretas. Nesse caso, a maneira de lidar com isso seria mover o método UpdateHours para a classe de funcionários. Esse é o cerne do modelo de modelo anêmico do modelo.

Answer 2

Eu acho que seu design está bem aqui. Como você sabe, o modelo de domínio anêmico anti-padrão é uma reação contra a tendência de evitar qualquer comportamento codificado em objetos de domínio. Mas inversamente não significa tudo O comportamento relacionado a um objeto de domínio deve ser encapsulado por esse objeto.

Como regra geral, o comportamento intrinsecamente ligado ao objeto de domínio e é definido inteiramente em termos dessa instância do objeto de domínio pode ser incluído no objeto de domínio. Caso contrário, para manter as responsabilidades claras, é melhor colocá -lo externamente em um colaborador/serviço como você fez.

Answer 3

Está tudo na sua cabeça - considere o serviço de rotação como parte do modelo de domínio e o problema se dissolve.

A rotação precisa manter as informações sobre muitos funcionários, por isso pertence a não liderar, nem a nenhum objeto de funcionário. É para merecer ser um objeto de domínio em si.

Apenas renomear "RotationService" para algo como "organização.UserSupportDepartment" torna isso óbvio.

Answer 4

Se o seu modelo de domínio contiver apenas papéis e coisas, não atividades como comportamento, é anêmico. No entanto, estou falando de comportamento em relação a um modelo não um objeto. Eu falo da diferença entre eles em outra resposta ... https://stackoverflow.com/a/31780937/116442

Da sua pergunta, você quebra minhas duas primeiras regras de modelagem de análise de domínio:-

1. O comportamento modelado como atividades (registradas) estão no coração de um modelo de domínio. Adicione -os primeiro.
2. Modelo de atividades de domínio como classes, não métodos.

Eu acrescentaria uma atividade "inquérito" ao modelo. Com ele, o modelo tem comportamento e pode combinar e trabalhar como grupo de objetos sem um controlador ou script externo.