Arquitectura de sistemas

¿A qué nos referimos cuando hablamos de la arquitectura de una aplicación?. Nos referimos a los componentes en que la vamos a dividir y como se van a relacionar estos componentes. Hablamos también de las divisiones físicas y lógicas en que vamos a dividir la aplicación con el objetivo de cumplir con los requerimientos técnicos (no funcionales).

¿y de qué NO hablamos?. No hablamos de cómo, la aplicación, va a resolver el negocio en cuestión.

Entonces... ¿que esperamos de la arquitectura de nuestra aplicación?. Esperamos que resuelva las necesidades técnicas sin hacer más complejo el trabajo de los programadores que desarrollan el negocio. Que su implementación no sea costosa a nivel performance y que no perdamos las ventajas de cada entorno en aires de generalizar para todos los escenarios posibles (e imposibles). El equilibrio entre estos puntos, y otros que me estaré olvidando e iremos completando, es el desafío.

Podríamos pretender que la arquitectura nos permita evolucionar, que podamos refactorizar y tengamos la certeza que todo sigue funcionando. Que si encontramos otra forma mejor de resolver un requerimiento, no sea difícil el cambio. Y con esto ya se empiezan a filtrar conceptos de metodología que también iremos discutiendo.

El ejemplo que vamos a ir armando es sobre la base de datos Chinook 1.1, veremos la implementación de varios frameworks y por qué lo hacemos.

El código fuente ya empieza a estar disponible, aunque en constante refactorización.