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.
Amén!
ResponderEliminarBasado en un post estupendo de SapiensWorks.
ResponderEliminarhttp://www.sapiensworks.com/blog/post/2012/04/07/Just-Stop-It!-The-Domain-Model-Is-Not-The-Persistence-Model.aspx