La Ciudad de los Componentes

En el Desarrollo de Software vivimos en la Era de los Componentes, tanto en el lado Front-end como en el Back-end. La fiebre por la Componentización proviene de conceptos definidos ya hace muchos años en el diseño de Servicios y, más modernamente, en la Arquitectura Orientada a Servicios (Service-Oriented Architecture o SOA en inglés) que luego ha derivado en patrones de diseño como los Servicios Web, los Microservicios o la Arquitectura Dirigida por Eventos (Event-Driven Architecture o EDA en inglés). Hablemos de algunos de estos conceptos.

Separación de Preocupaciones

Antes de la fiebre por la Componentización hubo otra en el diseño de software: la fiebre por las Capas. El diseño de Capas en sistemas de información es más antiguo pero también obedece a un principio común: la Separación de Preocupaciones (Separation of Concerns en inglés), un principio que establece la necesidad de desacoplar piezas del sistema, encapsulando en ellas información y exponiendo una interfaz que facilita su uso desde el exterior. Un sistema que implementa la Separación de Preocupaciones suele hacerlo de manera moderna a través de la Modularidad.

Modularidad

Una vez que entendemos el valor crucial de separar las funcionalidades de un sistema, encapsularlas y exponer un contrato para utilizarlas llegamos al concepto de Módulo que incluye el valor de ser intercambiable. En Front-end es muy bueno para entender lo que puede suponer un módulo tomar la acepción que nos brinda Webpack y que incluye piezas reutilizables de estilos, de marcado o de JavaScript. La composición de estas piezas para concebir una entidad funcional reutilizable es lo que en Front-end acaba por definir a un Componente.

Composición

En el complejo mundo del Desarrollo de Software un principio elemental de reutilización es la Composición. Un Componente se forma a partir de piezas (desacopladas en módulos o no) pero a su vez puede ser parte de una composición a otra escala junto a otros componentes. En el Front-end moderno se ha popularizado la representación de una aplicación como un Árbol de Componentes con relaciones de padres e hijos en nodos vinculados en muchas ocasiones por flujos de datos y sistemas de mensajería. La Composición de Componentes, su Interactividad y su Orquestación son probablemente los puntos de complejidad y disensión más importantes entre las diferentes soluciones que ofrecen los estándares, las librerías y los frameworks.

Diseñando Componentes Gráficos

Y es aquí donde llega el núcleo de este artículo. El diseño de software moderno, especialmente en Front-end, está indisolublemente vinculado al Diseño Gráfico y de Interacción que no es sino la representación visual y/o interactiva de la interfaz que ofrecemos al usuario final del Producto. Por tanto la Componentización que ya está dejando de ser opcional en Front-end ha de tener un pacto explícito con el Diseño Gráfico que trata de representar, un reflejo directo en la metodología del Diseñador UI/UX y por extensión en la de todo el Equipo (Producto, Diseño, Desarrollo) que aborde la Definición de Componentes de una manera holística, horizontal y abierta.

Esto nos lleva a varios frentes. El primero es el del Lenguaje Común, concepto crucial en el Desarrollo Dirigido por Dominio (Domain-Driven Design o DDD en inglés) y que debe establecerse en un equipo sano y horizontal para compartir tanto la esfera de conocimiento o Dominio que aplica al Producto como los conceptos básicos de su Diseño (en la acepción más abstracta de la palabra, aunando tanto el Diseño Visual como el Diseño de Software y el de Producto) como el que nos atañe de Componente.

El segundo frente es el de romper la habitual Cascada. Es necesario desterrar el flujo en el que el Diseño Gráfico Final llega al desarrollador y éste debe limitarse a ejecutarlo. Todo el Equipo debe entender y participar de la Definición de Componentes, construyendo una Biblioteca con ellos, de piezas reutilizables tanto para el Diseñador de Producto, como para el Diseñador Gráfico y de Interacción, como para los Desarrolladores Front-end.

De lo contrario la Componentización en el diseño de software de Front-end está condenada al fracaso, la ineficiencia, la duplicidad y, como es bien conocido, al despilfarro de recursos y presupuestos. Si sólo el Desarrollador asume la Definición de Componentes, éstos se verán sujetos a cambios constantes e incluso no podrán ser reutilizados.

Conclusión

Componentización como concepto común a todo el Equipo que participe en el Diseño de Software. Este salto mental es cada vez más necesario. Si la tecnología avanza en una dirección que nos permite horizontalizar el proceso de Diseño de Software y optimizarlo a través de patrones comunes a un nivel de abstracción elevado como es el Diseño de Componentes Reutilizables, debemos tener la visión necesaria para aprovecharlo.

Una reflexión más avanzada nos permitiría adentrarnos en otros aspectos del Diseño Dirigido por Dominio como la Definición de Contextos Vinculados, de Entidades o de Eventos de Dominio a nivel de Equipo, construyendo una Identidad que diese sentido a toda la implementación posterior de las diferentes áreas (Producto, Diseño Gráfico y Desarrollo).

Pero eso, me temo, da para muchos otros artículos.