anemic domain model - resueltos - Evitar el modelo de dominio anémico: un ejemplo real

modelo de dominio simbologia

Question

Estoy tratando de entender los Modelos de Dominio Anemico y por qué son supuestamente un antipatrón.

Aquí hay un ejemplo del mundo real.

Tengo una clase de empleado, 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 consiste en girar las llamadas telefónicas entrantes y las consultas en el sitio web (conocidas como ''clientes potenciales'') de manera uniforme entre el personal de ventas. Este sistema es bastante complejo ya que involucra consultas de rutina, verificación de vacaciones, preferencias de los empleados, etc. Por lo tanto, este sistema está actualmente separado 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
}
}

Luego, en la parte posterior de nuestro formulario de consulta del sitio 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 supuestamente es algo de lo que debería salir gritando porque es un Modelo de Dominio Anémico .

Pero para mí no está claro dónde debe ir la lógica del servicio de rotación principal. ¿Debería ir a la cabeza? ¿Debería ir en el empleado?

¿Qué pasa con todos los repositorios inyectados, etc. que requiere el servicio de rotación? ¿Cómo se inyectarían en el empleado, dado que la mayoría de las veces al tratar con un empleado no necesitamos ninguno de estos repositorios?

Answer 1

Creo que tu diseño está bien aquí. Como saben, el anti-patrón del modelo de dominio anémico es una reacción contra la tendencia de evitar cualquier comportamiento codificado en objetos de dominio. Pero, por el contrario, no significa que todo el comportamiento relacionado con un objeto de dominio debe ser encapsulado por ese objeto.

Como regla general, el comportamiento que está intrínsecamente vinculado al objeto de dominio y se define por completo en términos de esa instancia de objeto de dominio se puede incluir en el objeto de dominio. De lo contrario, para mantener las responsabilidades claras, lo mejor es exponerlo externamente en un colaborador / servicio como lo ha hecho.

Answer 2

En este caso, esto no constituye un modelo de dominio anémico. Un modelo de dominio anémico trata específicamente de validar y transformar los objetos . Así que un ejemplo de esto sería si una función externa realmente cambió el estado de los empleados o actualizó sus detalles.

Lo que está sucediendo en este caso es que está tomando todos los empleados y haciendo una selección de uno de ellos en función de su información. Está bien tener un objeto separado que examine a los demás y tome decisiones con respecto a lo que encuentre. NO es correcto tener un objeto que se utiliza para hacer la transición de un objeto de un estado a otro.

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

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

eso toma un objeto Empleado y actualiza sus horas trabajadas para la semana, asegurándose de que las banderas se levanten si las horas exceden un cierto límite. El problema con esto es que si solo tiene objetos Employee, entonces no tiene conocimiento de cómo modificar sus horas dentro de las restricciones correctas. En este caso, la forma de manejarlo sería mover el método updateHours a la clase Employee. Ese es el quid del patrón anti Patrón Anemic.

Answer 3

Si su modelo de dominio contiene solo roles y cosas, no actividades como comportamiento, entonces es anémico. Sin embargo, estoy hablando de comportamiento con respecto a un modelo, no a un objeto . Hablo de la diferencia entre ellos en otra respuesta ... https://.com/a/31780937/116442

De su pregunta, usted rompe mis dos primeras reglas de modelado de análisis de dominio:

1. Comportamiento modelado como (registrado) Las actividades están en el corazón de un modelo de dominio. Agréguelos primero.
2. Modele las actividades de dominio como Clases, no como métodos.

Agregaría una actividad "Inquiry" al modelo. Con él, el modelo tiene un comportamiento, y puede combinar y trabajar como un grupo de objetos sin un controlador externo o secuencia de comandos.

Answer 4

Todo está en tu cabeza: considera que el servicio de rotación forma parte del modelo de dominio y el problema se disuelve.

La rotación necesita mantener la información sobre muchos empleados, por lo que no pertenece a ningún cliente potencial, ni a ningún objeto empleado individual. Lo hace para merecer ser un objeto de dominio en sí mismo.

Simplemente renombrar "RotationService" a algo así como "Organization.UserSupportDepartment" lo hace obvio.