Evitar modelo de dominio anémico - un ejemplo real

Question

Estoy tratando de entender los modelos de dominio anémico y por qué se supone que son un anti-patrón.

Aquí hay un ejemplo del mundo real.

Tengo una clase de empleados, que tiene un montón de propiedades - nombre, sexo, nombre de usuario, etc.

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

A continuación tenemos un sistema que implica la rotación de las llamadas telefónicas entrantes y consultas sitio web (conocidos como 'pistas') de manera uniforme entre el personal de ventas. Este sistema es bastante complejo, ya que implica ronda robining consultas, la comprobación de las vacaciones, las preferencias de los empleados, etc. Así que este sistema se separa actualmente a cabo en un servicio:. 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
     }
}

A continuación, en la parte trasera de nuestro formulario de consulta web tenemos un 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.");
}

realmente no encuentro muchos problemas con este enfoque, pero se supone que esto es algo que debería correr gritando desde ya que es un anémico modelo de dominio .

Pero para mí no está claro donde la lógica en el servicio de rotación principal debe ir. En caso de que vaya a la cabeza? En caso de que vaya en el empleado?

¿Qué pasa con todos los repositorios inyectados etc que el servicio requiere la rotación -? ¿Cómo iban a ser inyectados en el empleado, dado que la mayoría de las veces cuando se trata de un empleado que no necesita cualquiera de estos repositorios

Answer 1

En este caso, esto no constituye un modelo de dominio anémico. Un modelo de dominio Anemic es específicamente sobre la validación y la transformación de los objetos . Por lo tanto un ejemplo de esto sería si una función externa en realidad cambia el estado de los empleados o actualiza sus datos.

lo que está sucediendo en este caso es que usted está tomando todos los empleados y hacer una selección de una de ellas en función de su información. Es bueno tener un objeto independiente que examina los demás y toma decisiones con respecto a lo que encuentra. No es buena para tener un objeto que se utiliza para la transición de un objeto desde un estado a otro.

Un ejemplo de un modelo de dominio anémico en su caso sería contar con un método externo

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

que toma un objeto Employee y actualiza sus horas de trabajo para la semana, asegurándose de que las banderas se plantean si las horas exceden un cierto límite. El problema con esto es que los objetos si sólo tiene Empleado entonces no tienen conocimiento de cómo modificar sus horas dentro de los límites correctos. En este caso, la manera de tratar con él sería mover el método updateHours en la clase Empleado. Ese es el quid de la pauta contra anémico modelo de dominio.

Answer 2

Creo que su diseño es bien aquí. Como usted sabe, el modelo de dominio anémico anti-patrón es una reacción en contra de la tendencia de evitar cualquier comportamiento codificado en objetos de dominio. Pero por el contrario no significa todos comportamiento en relación con un objeto de dominio debe ser encapsulado por dicho objeto.

Como regla general, comportamiento que se intrinsicly ligado al objeto de dominio, y se define totalmente en términos de que instancia de objeto de un dominio puede ser incluido en el objeto de dominio. De lo contrario, para mantener responsabilidades claras, lo mejor es ponerlo en un colaborador externo / servicio como el que ha hecho.

Answer 3

Todo está en tu cabeza -. Considerar el servicio de rotación para ser una parte del modelo de dominio y que se disuelva el problema

Rotación necesita mantener información acerca de muchos empleados, por lo que no pertenece ni plomo, ni a cualquier objeto solo empleado. Lo hace para merecer ser un objeto de dominio en sí mismo.

Sólo el cambio de nombre "RotationService" a algo así como "Organization.UserSupportDepartment" hace que sea obvio.

Answer 4

Si su modelo de dominio contiene sólo las funciones y actividades de las cosas, no como el comportamiento, entonces es anémica. Sin embargo, estoy hablando sobre el comportamiento en lo que se refiere a un modelo de no es un objetos . Hablo de la diferencia entre ellos en otra respuesta ... https://stackoverflow.com/a/31780937/116442

A partir de su pregunta, romper mis primeras reglas de modelado de análisis de dos dominios: -

1. Comportamiento modelado como Actividades (grabadas) están en el corazón de un modelo de dominio. Añadirlos primero.
2. actividades dominio del modelo como clases, no métodos.

Yo añadiría una actividad "mensaje" al modelo. Con él, el modelo tiene un comportamiento, y se puede combinar y el trabajo como grupo de objetos sin un controlador externo o script.