martes, 27 de enero de 2015

El modelo de dominio es EL MODELO.

Diseñar primero el esquema de datos en persistencia es un fallo tremendo y, por lo visto, muy común.

El Dominio es la razón por la que la aplicación existe y todo debe gravitar alrededor de el. El dominio no debe depender de nada, y mucho menos de detalles de implementan de persistencia.

El esquema de persistencia debe de estar al servicio del modelo de dominio y no al revés. Una vez que se tienen diseñadas las entidades, sus relaciones y los servicios de dominio es cuando se debe crear un esquema de datos que permita persistir en el tiempo esa información.

Si diseñamos el esquema de persistencia primero; nuestros servicios y entidades se van a ver llenas de hacks y workarrounds de lo más bizarros, que permitan casar los casos de uso del dominio con la persistencia; puesto que ésta no ha sido diseñada para el dominio, si no que ha sido diseñada simplemente para evitar redundancias e inconsistencia de datos sin tener en cuenta las necesidades de las operaciones y reglas del dominio; ya que estas todavía no han sido analizadas, modeladas ni probadas.

Esta es la razón por la que Eric Evans recomienda empezar el desarrollo diseñando el dominio e ignorar completamente cualquier cosa relativo a la persistencia.

Es la persistencia la que se debe adaptar al dominio. Es por esto, por lo que existen incluso técnicas para adaptar un diseño orientado a objetos a persistencia relacional:


Tabla por jerarquía: Desnormaliza el esquema y utiliza una columna discriminadora.

Tabla por tipo: Representa herencia utilizando relaciones.
Tabla por clase concreta: La persistencia relacional no es consciente de ninguna herencia puesto que no se representa de ninguna manera.



Regla de Oro: Cuando desarrollas una aplicación la persistencia NO EXISTE. 


Primero diseña una aplicación que cumpla el dominio; en la que tus entidades estén simplemente en arrays en memoria y que cada vez que arranques la aplicación la información desaparezca. Una vez tienes esto completado es la hora de crear un esquema de persistencia que permita almacenar las entidades y sustituir los repositorios que almacenan y buscan en los arrays por repositorios que almacenan y buscan en persistencia; y todo esto sin modificar absolutamente nada del dominio.

Si diseñas primero la base de datos lo estás haciendo MAL y mal te saldrá la aplicación.

2 comentarios:

  1. Basado en un post estupendo de SapiensWorks.
    http://www.sapiensworks.com/blog/post/2012/04/07/Just-Stop-It!-The-Domain-Model-Is-Not-The-Persistence-Model.aspx

    ResponderEliminar