El modelo de dominio anémico es el uso de un modelo de dominio de software donde los objetos de dominio contienen poca o ninguna lógica comercial (validaciones, cálculos, reglas comerciales, etc.).
Descripción general
Este patrón fue descrito por primera vez [1] por Martin Fowler , quien considera la práctica un anti-patrón . Él dice:
El horror fundamental de este anti-patrón es que es tan contrario a la idea básica del diseño orientado a objetos; que consiste en combinar datos y procesarlos juntos. El modelo de dominio anémico es solo un diseño de estilo procedimental, exactamente el tipo de cosas que los fanáticos de los objetos como yo ... han 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, pierden por completo el sentido 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 estos scripts de transacciones de clases externas . Este patrón es un enfoque común en Java aplicaciones, posiblemente alentado por tecnologías como las primeras versiones de EJB 's Entity Beans , [1] así como en .NET las aplicaciones siguientes de la arquitectura de aplicaciones de servicios de tres en capas, donde estos objetos entran en la categoría de "Entidades Comerciales" (aunque las Entidades Comerciales también pueden contener comportamiento). [2]
Fowler describe el patrón de secuencia de comandos de transacción así:
La mayoría de las aplicaciones comerciales se pueden considerar como una serie de transacciones. Una transacción puede ver cierta información organizada de una manera particular, otra hará 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 Transaction Script organiza toda esta lógica principalmente como un solo procedimiento, realizando llamadas directamente a la base de datos o mediante 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 secuencia de comandos de transacciones está bien para muchas aplicaciones comerciales simples y evita una capa compleja de mapeo de bases de datos OO.
Razones por las que esto puede ocurrir
AnemicDomainModel puede ocurrir en sistemas que están influenciados por arquitecturas orientadas a servicios, donde el comportamiento no viaja o tiende a no viajar.
- Arquitecturas de mensajería / canalización
- API como SOAP / REST
Arquitecturas como COM + y Remoting permiten el comportamiento, pero la web ha favorecido cada vez más las arquitecturas desconectadas y sin estado.
Crítica
Hay algunas críticas sobre si este patrón de diseño de software debe considerarse un antipatrón, ya que muchos también ven beneficios en él, por ejemplo:
- Separación clara entre lógica y datos. [4]
- Funciona bien para aplicaciones sencillas.
- Da como resultado una lógica sin estado, que facilita el escalado horizontal.
- Evita la necesidad de una capa de mapeo compleja de OO-Database.
- Más compatibilidad con marcos de mapeo e inyección que esperan propiedades tontas en lugar de un constructor específico o un orden de población de propiedades. [4]
Pasivo
- La lógica no se puede implementar de una manera verdaderamente orientada a objetos.
- Violación de los principios de encapsulación y ocultación de información .
- Necesita una capa empresarial separada para contener la lógica que de otro modo se ubicaría en un modelo de dominio . También significa que los objetos del modelo de dominio no pueden garantizar su corrección en ningún momento, porque su lógica de validación y mutación se coloca en algún lugar exterior (muy probablemente en varios lugares).
- Necesita una capa de servicio cuando se comparte la lógica de dominio entre diferentes consumidores de un modelo de objeto.
- Hace que un modelo sea menos expresivo.
Ejemplo
Anémico
class Box { public int Height { get ; establecer ; } public int Width { get ; establecer ; } }
No anémico
class Box { public int Height { get ; } public int Width { get ; } Public Box ( int altura , int ancho ) { if ( altura <= 0 ) { lanzar nueva ArgumentOutOfRangeException ( nombre de ( altura )); } if ( ancho <= 0 ) { lanzar una nueva excepción ArgumentOutOfRangeException ( nombre de ( ancho )); } Altura = altura ; Ancho = ancho ; } public int Area () { return Alto * Ancho ; } }
Ver también
- Plain Old Java Objeto
- Diseño impulsado por dominios
- Experto en información GRASP , un modelo de dominio anémico es el resultado típico de no aplicar el principio de experto en información, es decir, puede evitar un modelo de dominio anémico al intentar asignar responsabilidades a las mismas clases que contienen los datos
Referencias
- ^ a b http://www.martinfowler.com/bliki/AnemicDomainModel.html
- ^ "Copia archivada" . Archivado desde el original el 10 de enero de 2013 . Consultado el 13 de febrero de 2013 .CS1 maint: copia archivada como título ( enlace )
- ^ https://www.martinfowler.com/eaaCatalog/transactionScript.html
- ^ a b http://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/
enlaces externos
- Modelo de dominio anémico de Martin Fowler
- Aplicación de servicios de tres capas
- Arquitectura de aplicaciones para .NET: diseño de aplicaciones y servicios
- Artículo sobre por qué un modelo anémico puede considerarse un buen diseño
- Escribir código limpio en ASP.NET
- Cómo evitar el modelo de dominio anémico