10 de octubre de 2015

¿Shared Database es un antipatrón?

Según la definición del estilo de integración Shared Database: "la integración de aplicaciones construidas de manera independiente almacenando sus datos en una misma y única base de datos".



Sin embargo, En 2010, Ian Nelson elaboró una lista de anti-patrones de integración empresarial (Enterprise Integration Anti-Patterns), en la cual destacó al patrón Shared Database como el número uno de aquellos patrones que no deberían ser considerados como tales.

Nelson explica que compartir una base de datos entre diferentes aplicaciones "es una mala idea" por lo siguiente:

- Se rompe el enfoque de soluciones fáciles de mantener y mejorar, puesto que eventuales cambios en la base de datos van a implicar tomar en cuenta ya no sólo las necesidades de la aplicación primaria, sino de las demás que se han integrado, haciendo más complejo su mantenimiento.

- Se vulnera la arquitectura en capas trabajado sobre la aplicación primaria, ya que programas ajenos a esta implementación podrán acceder directamente a la base de datos.

- Se crean problemas en el uso de patrones de persistencia como NHIbernate.

- Se pone en riesgo el cumplimiento de los requerimientos no funcionales, pues cualquier consideración que se tuvo sobre las capacidades del servidor de datos (caché, bloqueos, seguridad, etc.) se ve perjudicado.


Por otro lado, Ben Morris, un conocido especialista sobre arquitecturas de software, coincide con las consideraciones de Nelson, señalando además que:

- Las bases de datos compartidas hacen difícil de definir las fronteras entre los sistemas.

- Propician que los desarrolladores se encapsulen en una única solución sin explorar otras alternativas para solucionar el problema planteado ante la necesidad de tener la información integrada y oportuna.

Referencias:
http://www.ianfnelson.com
http://www.ben-morris.com
http://www.eaipatterns.com
http://www.troyhunt.com