Frecuentemente se argumenta que la reutilización es uno de los valores más importantes de las soluciones de software. En efecto, cuando desarrollamos arquitecturas, uno de nuestros objetivos fundamentales es conseguir que los activos construidos puedan ser reutilizados en diferentes contextos arquitectónicos de uso. Entre otras cosas, esto contribuye al ahorro de costes en los procesos de desarrollo y a la homogeneidad transversal de las soluciones. Todo paradigma y en particular la orientación a objetos caracterizada por los principios SOLID ha promovido modelos de construcción orientados a la reutilización. Se argumenta que la construcción de objetos es el camino mediante el cual estos activos pueden ser de aplicación en diferentes contextos arquitectónicos siempre que se diseñen con el nivel adecuado de abstracción y desacoplamiento. Sin embargo, cuando nos adentramos en nuevos paradigmas de programación como aquellos propios de la orientación a componentes encontramos que frecuentemente construir menos asiste más en los procesos de reutilizar más. Bajo esta hipótesis parece más interesante de cara la reutilización crear contribuciones parciales que puedan extender el comportamiento o estructura de los componentes para que adopten nuevas capacidades de forma dinámica y convertir a estos rasgos de contribución puntual en los activos esenciales de la reutilización.
Los procesos de construcción de soluciones de software pasan habitualmente por la creación de arquitecturas sólidas. Este tipo de diseños son aquellas que cumplen con los principios fundacionales del paradigma de la orientación a objetos, de sus siglas en inglés SOLID. Sin embargo, en ocasiones resulta conveniente aplicar otro tipo de estrategia para la creación de software. Esto es especialmente cierto en aquellos casos en los que se pretenda dar con soluciones que resulten flexibles y plásticamente adaptables a distintos contextos de uso. El uso de determinadas técnicas y modelos de diseño arquitectónico tal es como el uso de traits, mixins, roles, aspectos o subjects, propios del paradigma de la orientación a componentes, es de aplicación en estos casos. Muchos lenguajes, de hecho, invitan a llevar a cabo un proceso de ideación de soluciones basado en estas técnicas dando lugar a soluciones más flexibles y dinámicamente cambiantes a tenor de las condiciones ambientales. A lo largo de esta charla se hace un recorrido exhaustivo de este paradigma arquitectónico revisando los principios, técnicas y modelos sobre la base del stack tecnológico de la plataforma web.
Frecuentemente, cuando desarrollamos productos digitales basados en componentes web, de manera consciente o inconsciente, aplicamos los principios del paradigma de orientación objetos, aquellos referidos habitualmente a través de sus siglas en ingles SOLID. Este hecho conduce a soluciones bien formadas, sólidas y robustas. Sin embargo, con frecuencia este tipo de problemas requiere de aproximaciones divergentes que aplican técnicas y modelos arquitectónicos de metaprogramación más propios del paradigma clásico de la orientación a componentes. Se trata, en este sentido, de idear soluciones con una capacidad de adaptación plástica y dinámica al contexto arquitectónico de uso particular que sean capaces de elevar las cotas de reutilización potencial de los activos construidos. De acuerdo a estas ideas, el foco no está tanto en la construcción de los componentes idóneos para resolver problemas particulares sino de ser capaces de crear estrategias de transformación adaptativa que provoquen cambios puntuales irreversibles sobre la estructura y comportamiento de los componentes y de encapsular esas estrategias en activos arquitectónicos de primer nivel para contribuir de manera formal y sistemática sobre el cuerpo de cualquier componente.
La transformación cultural que vino de la mano de las metodologías ágiles puso rápidamente foco de atención en los procesos de desarrollo de software. Se trataba de crear productos más orientados al cliente con una participación activa del mismo en los procesos continuos de toma de decisiones y permitir que el proceso de construcción de los productos digitales fuera más una actividad de exploración y descubrimiento continuo sobre un espacio de problemas que el cumplimiento de un conjunto de requisitos y restricciones definidos, bajo contrato legal, en el marco de un pliego de proyecto. La comunidad de desarrollo de software aprendió rápidamente estas lecciones y empezó a aplicar una cultura del desarrollo fresca y dinámica basada en la resolución dialogada de problemas a través de metodologías de time boxing y procedimientos iterativos e incrementales. Si bien se puso mucho foco de atención en evangelizar sobre estas nuevas ideas en la literatura y en Internet, no se ha hecho tanto estrés en relación a que significa practicar el agilismo desde la actividad del diseño arquitectónico. Crear arquitecturas ágiles significa romper con los prejuicios de otras épocas en las que el ejercicio arquitectónico se entendía como una actividad de oráculo en el esfuerzo de crear un todo sistémico bien formado e inamovible. En su lugar hacer arquitecturas ágiles significa ser capaz de promover esfuerzos exploratorios de alcance local para resolver cada problema inmediato en el marco temporal en el que se aborda sin conflictos con las ideas de una construcción basada en la destrucción continua e incremental.