El modelo de dominio anémico se describe como un antipatrón de programación en el que los objetos de dominio contienen poca o ninguna lógica empresarial, como validaciones, cálculos, reglas, etc. La lógica empresarial está, por tanto, incorporada a la arquitectura del propio programa, lo que hace que la refactorización y el mantenimiento sean más difíciles y lleven más tiempo.
Este antipatrón fue descrito por primera vez [1] por Martin Fowler , quien considera la práctica como un antipatrón . Dice:
El horror fundamental de este antipatrón es que es totalmente contrario a la idea básica del diseño orientado a objetos, que es combinar datos y procesos. El modelo de dominio anémico es simplemente un diseño de estilo procedimental, exactamente el tipo de cosas contra las que los fanáticos de los objetos como yo... hemos estado luchando desde nuestros primeros días en Smalltalk . Lo que es peor, muchas personas piensan que los objetos anémicos son objetos reales y, por lo tanto, pasan por alto por completo lo esencial del diseño orientado a objetos.
En un diseño de dominio anémico, la lógica empresarial se implementa típicamente en clases separadas que transforman el estado de los objetos del dominio. Fowler llama a estas clases externas scripts de transacción . Este patrón es un enfoque común en aplicaciones Java , posiblemente fomentado por tecnologías como las primeras versiones de los Entity Beans de EJB , [1] así como en aplicaciones .NET que siguen la arquitectura de aplicación de servicios de tres capas donde dichos objetos caen en la categoría de "Entidades empresariales" (aunque las Entidades empresariales también pueden contener comportamiento). [2]
Fowler describe el patrón de script de transacción de la siguiente manera:
La mayoría de las aplicaciones empresariales pueden considerarse como una serie de transacciones. Una transacción puede ver cierta información organizada de una manera particular, otra puede realizar cambios en ella. Cada interacción entre un sistema cliente y un sistema servidor contiene una cierta cantidad de lógica. En algunos casos, esto puede ser tan simple como mostrar información en la base de datos. En otros, puede implicar muchos pasos de validaciones y cálculos. Un script de transacción organiza toda esta lógica principalmente como un único procedimiento, que realiza llamadas directamente a la base de datos o a través de un contenedor de base de datos delgado. Cada transacción tendrá su propio script de transacción, aunque las subtareas comunes se pueden dividir en subprocedimientos. [3]
En su libro "Patrones de arquitectura de aplicaciones empresariales", Fowler señaló que el patrón de script de transacción puede ser adecuado para muchas aplicaciones empresariales simples y evita una compleja capa de mapeo de base de datos OO.
Un modelo de dominio anémico puede darse en sistemas influenciados por arquitecturas orientadas a servicios, donde el comportamiento no se transmite o tiende a no transmitirse, como las arquitecturas de mensajería/canalización o las API SOAP / REST . Arquitecturas como COM+ y Remoting permiten el comportamiento, pero cada vez más la web ha favorecido las arquitecturas desconectadas y sin estado.
Hay algunas críticas sobre si este patrón de diseño de software debería considerarse un antipatrón, ya que muchos también ven beneficios en él, por ejemplo:
Una crítica común es la idea de que el modelo de dominio anémico facilita el seguimiento de los principios SOLID :
“La 'S' se refiere al Principio de Responsabilidad Única , que sugiere que una clase debe hacer una cosa y hacerla bien (...)”. [5]
Pero, según Robert C. Martin , esto es un malentendido de ese principio:
"De todos los principios SOLID, el Principio de Responsabilidad Única (SRP, por sus siglas en inglés) es quizás el menos comprendido. Probablemente se deba a que tiene un nombre particularmente inapropiado. Es muy fácil para los programadores escuchar el nombre y luego asumir que significa que cada módulo debe hacer sólo una cosa. No nos equivoquemos, existe un principio de ese tipo. Una función debe hacer una, y sólo una, cosa. Usamos ese principio cuando estamos refactorizando funciones grandes en funciones más pequeñas; lo usamos en los niveles más bajos. Pero no es uno de los principios SOLID, no es el SRP. (...) la versión final del SRP es: Un módulo debe ser responsable ante un, y sólo un, actor. [6] "
Al utilizar un modelo de dominio anémico se introducen ciertas responsabilidades que el programador debe tener en cuenta:
Un modelo de dominio anémico tendría un código escrito como el siguiente (escrito en C# ), que por sí solo no implementa ninguna de las preocupaciones comerciales, en este caso, que una altura o un ancho no pueden ser cero o negativos, o que en algún otro lugar existe un requisito para el área del rectángulo. Esto significa que esas funcionalidades se implementan en otro lugar, ya no en el lado "comercial" del programa, sino en otro lugar oculto dentro de su arquitectura.
clase Rectángulo { público int Alto { obtener ; establecer ; } público int Ancho { obtener ; establecer ; } } Una reescritura no anémica de la clase anterior podría verse como la siguiente. Las cuestiones comerciales ahora se manejan en el objeto de dominio, mientras que la arquitectura puede ser más independiente del dominio. Esto permite que el programa asuma que ciertos atributos son verdaderos acerca de los objetos sin implementar controles de validez en otras partes de la arquitectura.
clase Rectángulo { int público Alto { obtener ; conjunto privado ; } int público Ancho { obtener ; conjunto privado ; } público Rectángulo ( int alto , int ancho ) { EstablecerAlto ( alto ); EstablecerAncho ( ancho ); } public void SetHeight ( int altura ) { if ( altura <= 0 ) { throw new ArgumentOutOfRangeException ( nameof ( altura )); } Altura = altura ; } público void SetWidth ( int ancho ) { si ( ancho <= 0 ) { arrojar nueva ArgumentOutOfRangeException ( nombrede ( ancho )); } Ancho = ancho ; } public int CalculateArea () { return Alto * Ancho ; } } {{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )