Tratando 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 ActiveRecord e ir por un enfoque DataMapper. En otras palabras, mis objetos de dominio no se ocuparían de persistir ellos mismos. Al hacerlo, parece que estoy invadiendo el anti-patrón del "modelo de dominio anémico". Por ejemplo, una de las entidades en mi programa es una Organización.

Una organización se representa como algo parecido a esto:

class Organization { 
    private $orgId; 
    private $orgName; 

    // getters and setters 
} 

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

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

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

¿Cómo manejas tus modelos de dominio en estas situaciones? ¿Quizás una organización no sea parte de mi dominio en primer lugar?

Answer 1

así, parece que esto al principio, pero cuando se le refactorizar el código sea más, que va a llegar a un cierto comportamiento para su clase de organización ...

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

O es posible cambiar la ubicación de la empresa, en lugar de establecer parámetros como la dirección, ciudad, estado en tres pasos, es posible añadir ChangeLocation(Street, City, State) método ..

Sólo tienes que ir paso a paso, cuando se encuentra con un cierto código de tu BL/capa de servicio que parece que debería pertenecer al dominio, muévela al dominio. Si lees Fowler, lo obtendrás muy pronto cuando lo veas en tu código.

Answer 2

¿Podría ser ahora anémico?

Por ejemplo, una vez que estaba desarrollando un sitio de registro de reunión/conferencia. Comenzó con solo una reunión.

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

Creo que es importante tener en cuenta que los dominios cambian con el tiempo y que su modelo puede terminar siendo refactorizado, por lo que incluso si pudiera parecer anémico, podría ser un poco demasiado futurista (como su organización la clase comenzará a obtener algunas configuraciones, reglas o preferencias o algo así).

Answer 3

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

Answer 4

También puede considerar que si no tiene muchas reglas comerciales, o el dominio no es tan complejo, esa DDD puede ser demasiado costosa para usted. DDD es una excelente solución para dominios grandes y complicados, pero es una gran cantidad de sobrecarga y complejidad si simplemente está haciendo data in, data out. La DDD es más difícil de diseñar e inherentemente agrega complejidad, por lo que para justificarla, la complejidad del dominio del problema debería superar eso.

Eso es todo lo que añadiría a zappan y epitka.