Capítulo 31: la web es un detalle - Clean Architecture

A finales de los 90 la web cambió las viejas arquitecturas cliente servidor. Aunque la web realmente no cambió nada si no que es simplemente la última oscilación que nuestra industria ha sufrido desde los años 60. Estas oscilaciones se mueven entre poner todo el poder de computación en servidores centrales y poner todo el poder de computación en los terminales.

Hemos visto varias de estas oscilaciones en esta última década o desde que la web ha cobrado tanta importancia. Al principio se pensó que todo el poder de computación estaría en granjas de servidores y los navegadores serían ser estúpidos. Entonces  se empezó a poner applets en los navegadores. Pero nosotros nos gustó eso, así que movimos contenido dinámico de vuelta a los servidores pero eso tampoco gustó y se inventó la web 2.0, volviendo a mover el procesamiento al navegador con Ajax y javascript. Hemos ido tan lejos que hemos creado aplicaciones enteras ejecutadas en los navegadores. Y ahora estamos todos emocionados de ejecutar JavaScript en el servidor con node.

El péndulo interminable

Por supuesto sería incorrecto pensar que aquellas oscilaciones empezaron con la web. Antes de la web, había arquitecturas cliente servidor. Antes de esto había minicomputadores centrales con matrices de terminales tontos. Antes de eso, había mainframes con terminales inteligentes de pantalla verde (que eran muy análogos a los navegadores modernos). Antes de eso, había salas de computadoras y tarjetas perforadas …
Y la historia continua. No se tiene claro dónde se quiere el poder de computación. Se va entre centralizar y distribuir y, de momento, esas oscilaciones continuarán por un tiempo.

Cuando miras en el cómputo global de la historia de IT, la web no cambió nada. La web fue simplemente una de las muchas oscilaciones que comenzaron antes de que la mayoría de nosotros naciera y continuará después de que muchos de nosotros nos hayamos retirado.

Como arquitectos, sin embargo, tenemos que mirar a largo plazo. Esas oscilaciones son solo problemas a corto plazo que queremos alejar del núcleo central de nuestras reglas comerciales.

Permíteme contarte la historia de la compañía Q. Compañía Q construyó un popular sistema financiero personal. Este era un aplicación de escritorio con una GUI muy útil. Me encantaba usarlo.

Luego vino la web. En su próximo lanzamiento, la compañía Q cambió la GUI para que se vea y se comporte como un navegador. ¡Estaba aturdido! ¿Qué genio del marketing decidió que el software de finanzas personales, que se ejecuta en una computadora de escritorio, debería tener el aspecto de un navegador web?

Por supuesto, yo odiaba la nueva interfaz. Aparentemente todo el mundo lo hacía también porque después de unas pocos de lanzamientos la compañía fue quitando gradualmente el aspecto de navegador y volvió el aspecto que tenía la GUI de escritorio.

Imagine que un genio del marketing convence a la alta gerencia de que toda la interfaz de usuario tiene que cambiar para parecerse más a la web. Que haces o más bien, ¿qué debería haber hecho antes de este punto para proteger su aplicación de ese genio del marketing?

Debería haber desacoplado las reglas de su negocio de su IU. No sé si los arquitectos Q habían hecho eso. Un día me encantaría escuchar su historia. Si hubiera estado allí en ese momento, ciertamente habría presionado mucho para aislar las reglas de negocio de la GUI, porque nunca se sabe lo que harán los genios del marketing a continuación.

Ahora, considera una compañía A, la cual crea una smartphone adorable. Recientemente esta libero una nueva versión de su  “sitema operativo” (es tan extraño que podamos hablar de un sistema operativo dentro de un teléfono). Entre otras cosas, esa actualización del “sistema operativo” cambió de forma significativa el look and feel de todas las aplicaciones. ¿Por qué? Porque algún genio de marketing lo hizo.

No soy un experto en el software dentro del dispositivo, así que no conozco si ese cambió causó alguna dificultades para el programador de las aplicaciones que corren en el teléfono. Yo espero que los arquitectos de A y los arquitectos de las apps, mantengan sus UI y reglas de negocio aisladas unas de otras porque hay siempre genios de marketing esperando a lanzarse al siguiente acoplamiento.

El resultado

El resultado es simplemente esto: la GUI es un detalle. La web es una GUI. Entonces la web es un detalle. Y, como arquitecto, desea poner detalles como ese detrás de los límites que los mantienen separados de su lógica comercial central.

Piensalo de esta manera: la web es un dispositivo de entrada y salida. En los 60 se aprendió el valor de escribir aplicaciones que fueran independientes de los dispositivos. La motivación por esta dependencia no ha cambiado. La web no es una excepción a esta regla.

¿Lo es? Se puede argumentar que una GUI, como la web, es tan única y rica que es absurdo buscar una arquitectura independiente del dispositivo. Cuando piensa en las complejidades de la validación de JavaScript o las llamadas AJAX de arrastrar y soltar, o cualquiera de la gran cantidad de otros widgets y gadgets que puede poner en una página web, es fácil argumentar que la independencia del dispositivo no es práctica.

Hasta cierto punto, esto es cierto. La interacción entre la aplicación y la GUI es "comunicativa" en formas que son bastante específicas para el tipo de GUI que tiene. El baile entre un navegador y una aplicación web es diferente del baile entre una GUI de escritorio y su aplicación. Intentar abstraer esa danza, la forma en que los dispositivos se extraen de UNIX, parece poco probable que sea posible.

Pero se puede abstraer otro límite entre las UI y la aplicación. Lo lógica de negocio se puede plantear como casos de uso, cada uno de los cuales realizan alguna función en nombre del usuario. Cada caso de uso se puede describir basado en los datos de entrada, el procesamiento y la salida de los datos. 

En algún punto del baile entre la UI y la aplicación, los datos de entrada están completos, permitiendo a los casos de uso ejecutarse. Una vez finalizado, los datos resultantes pueden retroalimentarse en el baile entre la IU y la aplicación.

Los datos de entrada completos y la salida de datos resultantes se puede ubicar en estructuras de datos y usada como valores de entrada y salida para un proceso que ejecuta el caso de uso. Con este enfoque, podemos considerar que cada caso de uso opera el dispositivo IO de la IU de manera independiente del dispositivo.

Conclusión

Este tipo de abstracciones no es fácil y ésta probablemente conllevará varias interacciones para que esté bien pero es posible hacerlo. Y desde que el mundo está lleno de genios de marketing, no es difícil ver que es necesario.