Dominio anémico

Este anti-patrón definido por Martin Fowler y Eric Evans como AnemicDomainModel refleja la situación donde, si bien existen objetos del dominio, éstos sólo contienen datos. Las reglas de negocio e interacción entre ellos -es decir, su comportamiento- generalmente se encuentran en servicios que están por encima del dominio.

Las críticas que hacen a esta aproximación son 2:

  • la separación de datos y comportamiento es contraria a la misma idea de Orientación a Objetos.
  • provoca que la lógica de acceso a base de datos acabe usando el patrón TransactionScript que es sólo una de las opciones para mapear Objetos y Relaciones.

En esencia, este anti-patrón fomenta la programación estructurada en la capa de servicios, que engulle responsabilidades del dominio e impide el aprovechamiento de la potencia de la Orientación a Objetos.

En mi experiencia en el mundo real, esta aproximación tiende a:

  • dispersar la lógica del dominio en varios componentes: típicamente en los servicios y controladores de las vistas, con lo que la comprensión de las reglas del sistema se hace más compleja.
  • provocar acoplamiento entre los componentes del sistema, dificultando la creación de tests. Para testear la lógica del dominio es necesario levantar contextos (los servicios o los controladores de las vistas) que no siempre es fácil de hacer, por lo que la gente tiende a no hacerlo.

Más información: