Dominio Anémico

Publicada en Publicada en Sin Categoria

Compartelo con tus amigos!

Estuve viendo (no solo en internet sino también con algunos colegas en las diversas tutorias que hago) que el tener un dominio anémico se ha vuelto tan popular últimamente que parece que nos hemos olvidado (o nunca lo supimos) que se trata de una Anti-patrón.

Lo principal con este Anti-patrón es que simplemente va en contra de la idea básica de diseño orientado a objetos; el cual es combinar los datos y el comportamiento en una única unidad; mientras que el modelo de dominio anémico viene a ser un estilo de diseño procedimental, donde se trata de representar los objetos del dominio pero sin comportamiento, esta representación hace que muchos piensen que de verdad están modelando el dominio, cuando no es así.

Hasta aquí el purismo orientado a objetos, hablemos de otras cosas relacionadas; uno de los problemas de tener un dominio anémico es que se pierden todas las ventajas que nos proporciona el diseño orientado a objetos y solo nos quedamos con las desventajas, como por ejemplo la necesidad de mapear un objeto a un almacenamiento persistente.

Creo que la mayor confusión para esto que es que hay muchos expertos de OO que recomiendan poner una capa de servicios procedimentales encima del modelo de dominio con el fin de crear una capa de servicios, pero esto nos conlleva a tener servicios que terminan siendo ‘Transaction Script’; lo que no es malo por si mismo ya que muchas veces es necesario tener estos servicios dentro de nuestro modelo, sin embargo ello no justifica tener un dominio sin comportamiento.

En el libro de Eric Evans ‘Domain Driven Design’ pone lo siguiente (traducido del ingles):

Application Layer [su nombre para la Capa de Servicio]: Define los trabajos que el software debe hacer y dirige los objetos de dominio para solucionar los problemas. Las tareas que esta capa es responsable son significativas para el negocio o son necesarias para la interacción con las capas de aplicación de otros sistemas. Esta capa se mantiene delgada. No contiene reglas o conocimientos empresariales, solo coordina las tareas y delega el trabajo a las colaboraciones de objetos de dominio en la siguiente capa. No tiene un estado que refleje la situación del negocio, pero puede tener estado que refleje el progreso de una tarea para el usuario o el programa.

Domain Layer (o capa de modelo): Responsable de representar los conceptos del negocio, contiene la información sobre la situación del negocio y las reglas de negocio. El Estado que refleja la situación empresarial es controlado y utilizado aquí, aunque los detalles técnicos de su almacenamiento se delegan en la infraestructura. Esta capa es el corazón del software empresarial.

La clave acá es que la capa de servicio se debe mantener delgada y toda la lógica clave debe estar en la capa de dominio.

Para terminar cito a Matin Fowler: “the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you’ve robbed yourself blind”

Compartelo con tus amigos!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *