Tratar con un modelo de dominio anémico

Question

Estaba tratando de separar mi DAL de mi Business Layer, y al hacerlo, decidí evitar cualquier enfoque de ActiveRecord y optar por un enfoque DataMapper. En otras palabras, mis objetos de dominio no se encargarían de persistir. Al hacerlo, parece que estoy invadiendo el "modelo de dominio anémico". antipatrón. Por ejemplo, una de las entidades en mi programa es una Organización.

Una organización se representa como algo así:

class Organization {
    private $orgId;
    private $orgName;

    // getters and setters
}

Entonces, básicamente, esta organización no hace nada más que actuar como "bolsa" (como dice Martin Fowler) para algunos datos. En el mundo PHP no es más que una matriz glorificada. No hay ningún comportamiento asociado con él.

Y el comportamiento en el programa, me he quedado atascado en el "nivel de servicio" clase como un OrganizationService que sirve principalmente como intermediario entre estos objetos y el DAL.

Aparte de los posibles problemas de escalado con PHP (tengo otras razones por las que insisto en `` embolsar '' mis datos en estos objetos), ¿está este enfoque totalmente fuera de lugar?

¿Cómo maneja sus modelos de dominio en estas situaciones? ¿Quizás una organización no es parte de mi dominio en primer lugar?

Answer 1

bueno, parece ser esto al principio, pero cuando refactorices más tu código, obtendrás algún comportamiento para tu clase de organización ...

un ejemplo en el que podría pensar ahora es que si tiene personas (empleados), es posible que desee asociarlos con la organización. por lo tanto, es posible que tenga un método AssociateEmployee (usuario empleado) que podría encontrar su lugar en la clase de su organización.

O puede cambiar la ubicación de la empresa, en lugar de establecer parámetros como dirección, ciudad, estado en tres pasos, puede agregar el método ChangeLocation (Street, City, State) ..

Simplemente vaya paso a paso, cuando encuentre algún código en su capa BL / servicio que parece que debería pertenecer al dominio, muévalo hacia el dominio. Si lee Fowler, lo recibirá muy pronto cuando lo vea en su código.

Answer 2

¿Podría ser anémico ahora?

Por ejemplo, una vez estaba desarrollando un sitio de registro de reuniones / conferencias. Comenzó con una sola reunión.

Todavía había una clase de reunión y solo una instancia, pero al año siguiente celebramos la conferencia, se amplió y se agregaron nuevas propiedades (para celebrar dos reuniones consecutivas), por lo que claramente no fue completamente desarrollado aún, ya que luego agregamos grupos de reuniones que podrían contener múltiples reuniones.

Por lo tanto, creo que es importante tener en cuenta que los dominios cambian con el tiempo y su modelo puede terminar siendo refactorizado, por lo que incluso si cree que es anémico, podría ser demasiado progresista (como su clase de organización comenzará a obtener algunas configuraciones, reglas o preferencias o algo).

Answer 3

También puede considerar que si no tiene muchas reglas de negocio, o el dominio no es tan complejo, DDD puede ser una sobrecarga para usted. DDD es una excelente solución para dominios grandes y complicados, pero es una gran carga y complejidad si simplemente está ingresando datos, datos fuera. DDD es más difícil de diseñar e inherentemente agrega complejidad, por lo que para justificarlo, la complejidad del dominio del problema debería superar eso.

Eso es todo lo que agregaría a zappan y epitka.

Answer 4

Su entidad no es anémica porque está tomando una capacidad de reposo que no debería estar allí para empezar. La persistencia y la captación de entidades es responsabilidad de los repositorios. Realmente su comportamiento debe estar en sus entidades, no en una capa de servicio. Pero explicar qué va a dónde está más allá de una simple respuesta. DDD de Eric Evans es un buen punto de partida.