Introducción: Como buen seguidor del blog del Maldo, leo sus posts en cuanto salen… los cuatro que hace en el año… y aunque en la encuesta contesté que tenía que dejar de escribir, no me hizo caso y algunos incluso le pidieron que siguiera escribiendo… Bueno, en cuestión de gustos no hay nada escrito… Para aminorar el daño, en una de las chácharas telefónicas rutinarias, le empecé a pelar el cable con la intencionalidad del sistema y la arquitectura, para que escribiera de cosas más apasionantes y le pusiera un poco más de color, pero como respuesta categórica solo obtuve un “escribelo vo po”. Oh drat! Tenía razón. Así que sin más preámbulo les dejo mi primer post para colaborar con el blog. Espero les guste.

Si consideramos que la arquitectura de software se define típicamente como la organización mayor de los elementos que componen un sistema, muchas veces sucede que el foco se centra en los detalles de implementación, los frameworks a utilizar, el stack de tecnología, entre otras. Se centra en cómo se presentará la aplicación, como se almacenarán los datos, incluso la elección del lenguaje de programación se convierte en un aspecto central. No cabe la menor duda de que todos estos detalles son importantes, pero, ¿que hay de la intención del sistema?

Robert Martin, mejor conocido como Uncle Bob hace un paseo muy interesante por el concepto que denomina Screaming Architecture, haciendo una analogía: imaginemos el plano de unas habitaciones, una cocina, un baño y un living comedor. La arquitectura grita “soy una casa”. Estoy de acuerdo de que con el diseño de un sistema debería suceder lo mismo. Sin embargo, no dejo de ver sistemas que lo que te muestran son Controllers, Views y Models; o DTO’s everywhere, o Data Layer, Business Layer, y Presentation Layer, etc. Todas estas cosas no te dicen nada en absoluto en cuanto a que diablos se trata de resolver. Es raro ver un sistema que con tan solo un vistazo puedes decir “esto es un sistema de inventario, o este es un sistema de venta de tickets. O este es un sistema para calcular que se yo… El diseño de un sistema debería hablar por sí mismo, expresando la intención del sistema, la solución de la problemática cual sea su razón de existir. El foco en el stack de tecnología o la organización del código no hace mas que desviar la atención del desarrollo en los detalles, introduciendo restricciones impuestas por estos mismos detalles de implementación.

Ahora bien, aún cuando nos concentremos en diferir al último momento responsable la decisión de aquellas variables arquitectónicas de mayor impacto, como una base de datos relacional, o un ORM específico, o un mecanismo de presentación tal o cual, concentrarse en el diseño del núcleo de la aplicación y capturar la mayor cantidad de conocimiento acerca del dominio del problema que se debe solucionar sigue siendo, en mi opinión, la parte más desafiante a la hora de desarrollar software. Hacer un cliente web, o una API REST, escribir un modelo de datos y un mecanismo de persistencia, es relativamente directo de realizar. Pero capturar la intención del sistema desacoplado de todos los detalles y dependencias que se situan en la periferia del sistema, y que solo prestan funciones específicas, es el verdadero desafío.

Conclusión: Una arquitectura exitosa es aquella que permite capturar, expresar, extender y ser flexible de cambiar la intención central del sistema, el denominado Dominio del problema, ganar conocimiento y aprender de este mismo (conocer mejor el negocio) y que permita diferir la decisión de aquellas variables arquitectónicas de mayor impacto hasta el último momento responsable. Cómo capturar esta intención es algo que me gustaría ir tratando en posts futuros.

Manténgase en línea. Cambio y fuera.

Disclaimer: Si disparé muchos balazos técnicos antes de explicarlos, ¡no desesperen!. La idea es no tirar toda la carne a la parrilla, para que tengamos más asados; tendremos mas posts para ir en breve por cada concepto. Y así, superamos los 4 posts al año del Maldo… ojalá sean 8