Archivos Mensuales: octubre 2012

Arquitecturas Hexagonales

Cuando desarrollas con un framework como Grails (aunque creo que vale para casí cualquiera: rails, play, diango, zen…) una de las cosas que aprecias es que montas la aplicación y empiezas a crear funcionalidad en minutos. La gestión de la base de datos y la implementación del patrón MVC está completamente integrada, con lo que los primeros pasos son ágiles. Creo esta tabla, accedo a ella, salvo registros, manipulo y opero y se los paso al controlador que los muestra en la vista.

Esta aproximación tiene algunas pegas, además de la ventaja que es tener la aplicación funcionando rápidamente. Resulta que no es una conclusión muy original, porque hay un montón de gente que la ha sacado:

En esta última referencia se añaden más al respecto, y seguramente habrá otro millon más dando vueltas por ahí que no he visto…

De todas maneras hemos sido muy felices desarrollando las aplicaciones completamente intregradas (o acopladas, según se mire) con el framework. ¿Cual es el problema? La verdad es que tiene algunos.

  • Connected Vs modular. El concepto es de @KentBeck, reflexionando sobre si merece la pena diseñar o no. Las aplicaciones van rápido hasta cierto momento de complejidad. Si la aplicación se mantiene por debajo de ese nivel, no hay ningún problema en hacerla “conectada”, sino diseñar y modularizar la aplicación si merece la pena.

  • Funcionar sin el framework. Si la aplicación, o mejor dicho, la lógica específica de la aplicación esta totalmente acoplada al framework, está… ¡¡totalmente acoplada al framework!! Así que no se cambia ni de framework (malo), ni se puede poner otra capa cliente por encima (servicios web o aplicación de escritorio o lo que inventen para el 2020), ni accedemos con otra tecnología… El hacerla modular y desacoplada de los mecanismos del framework solo tiene ventajas… esto es de primero de informática básica, pero he visto muchas aplicaciones mal diseñadas, con la lógica mal puesta sin necesitar un framework que te tiranice…
  • Si funcionamos sin framework podemos hacer que las pruebas corran rápido rápido, o al menos más rápido que con él.
  • Modularidad, encapsulación, claridad de diseño y por lo tanto de interpretación y de construcción de nuevas funcionalidades reutilizando componentes… vamos otra vez a primero de informática básica, pero es que algunos todavía andamos intentando superarlo.

 

Anuncios