En esta ocasión comentamos el esperadísimo libro de Uncle Bob: Clean Architecture donde uno de los gurús del Software Craftsmanship nos habla de su punto de vista de la arquitectura de sistema software.
1. Introducción
A estas alturas deberías conocer el libro “Clean Code”, que es guía indispensable para los (buenos) desarrolladores de software de los últimos lustros. Podríamos decir que es uno de los responsables de aglutinar todas las intenciones de muchos programadores “ágiles” para desarrollar código de calidad: código comprensible, mantenible sobre el que poder realizar una evolución. El impacto desde su lanzamiento en 2008 ha sido más que evidente.
Casi dos lustros después del lanzamiento de Clean Code, Uncle Bob (Robert C. Martin) se ha atrevido a hablar de “arquitectura” y de arquitectos, y digo bien, “se ha atrevido” porque es un término en duda por parte del desarrollo ágil. No es sino el principio número 11 (aunque no están numerados), del Manifiesto Ágil (2001) – del que Uncle Bob es uno de los culpables junto con otros como Kent Beck, Martin Fowler o Alistair Cockburn entre otros – enuncia:
“The best architectures, requirements, and designs
emerge from self-organizing teams.“
Por tanto un libro escrito por Uncle Bob después de Clean Code y que se atreva a hablar de su punto de vista de la arquitectura tiene que atraer al menos nuestra atención.
2. El libro
El libro está dividido en 34 capítulos cortos y sencillos de leer, y cada uno de ellos trata de un tema bien determinado, así que es un libro que se puede ir leyendo poco a poco en los ratos libres en el transporte público. Estos capítulos a su vez se agrupan en diferentes partes que les dan un contexto, así tenemos partes como la introducción, paradigmas de programación; principios de diseño; principios de componentes etcétera…
El contenido y la forma de exponerlo guarda bastantes similitudes con “Clean Code”: no trata de técnicas complejas y novedosas que haya que leer y releer, sino que expone su visión sobre temas habituales en la arquitectura: cómo dividir, cómo organizar en capas; cómo gestionar las dependencias; el impacto de las decisiones. No esperes técnicas y ejemplos concretos como puede suceder en el Patterns of Enterprise Application Architecture de Martin Fowler, sino toneladas de sentido común a alto nivel sobre arquitectura.
En este sentido es un libro que me ha gustado bastante. Siempre es un placer leer opiniones de expertos con gran experiencia (Uncle Bob lleva programando desde la década de los 60) poniendo un poco de sentido común a las cosas, dando pinceladas generales donde encajan las últimas novedades de arquitectura, aunque haya a quien le sorprendan. Algunas que me vienen a la mente:
- El uso de microservicios no debería tener un gran impacto en la arquitectura de la aplicación: se trata de comunicar a través de protocolos de red lo que se hace en un monolito en memoria. Pero usar microservicios no debería cambiar aspectos como la división de responsabilidades o de los componentes.
- La programación no ha cambiado apenas en 50 años: podríamos traer en una máquina del tiempo a un desarrollador de 1960 y en 24 horas podría ponerse a programar una aplicación actual. De igual modo si tomamos un sistema de 1960 no nos tomaría demasiado tiempo empezar a desarrollar.
- Si me das un programa que funciona pero que es complicado de cambiar, fallará en el siguiente cambio de requerimientos. Es mejor un programa que no funcione y que sea fácil de cambiar: se tardará poco en arreglar y será barato de adaptar a los cambios.
Si la arquitectura es la última prioridad (frente a que “funcione”), al final cada vez será más caro programar, y se llegará a un punto en el que será prácticamente imposible.
Vamos a hacer un breve repaso por las partes de las que consta.
3. Partes del libro
Parte 1: Introducción
Habla de la importancia de la arquitectura para justificar la existencia del libro y de sus consejos. Me resulta muy relevante un caso que expone de un proyecto real y su coste creciente a medida que el proyecto aumenta de tamaño y de gente necesaria: después de varias iteraciones, el coste por línea de código aumenta 100 veces, llegando a un punto de colapso por no cuidar la arquitectura.
También habla de los valores de software: el comportamiento (hacer que funcione) o el valor de la arquitectura. Desafortunadamente se suele primar el primero, lo que a medio y largo plazo tiene consecuencias.
Parte 2: Paradigmas de Programación
Hace un breve repaso por los tres paradigmas de desarrollo más utilizados hoy en día: estructurada, programación orientada a objetos y programación funcional. Lo hace desde el punto de vista de la arquitectura, para demostrar que cada uno de ellos impone una serie de restricciones a los desarrolladores, librándole de “molestias” como los punteros, las instrucciones “goto”, permitiendo la inversión de dependencia gracias al polimorfismo o dotando de inmutabilidad en la programación funcional. La verdad es que lo aborda desde un punto de vista bastante escéptico frente a los que pregonan las ventajas de cada paradigma.
Parte 3: Principios de diseño.
En esta parte hace una reflexión que me gusta bastante: el desarrollo de software es “recursivo” o “fractal”, por lo que los principios que se aplican a funciones o clases, también pueden aplicarse a más alto nivel como por ejemplo módulos de una arquitectura. De este modo explica los principios SOLID aplicados a módulos de arquitectura, con el fin de aplicar todos los beneficios de su uso a alto nivel.
Parte 4: Principios de componentes
Comienza con una reflexión histórica sobre qué es un componente (al final un .dll; .jar…). Posteriormente reflexiona sobre la cohesión de un componente: qué entra en un componente y qué debe dejarse fuera: para ello usa diferentes principios como el de “reuse/release”, “common clousure” o “common reuse”. Son puntos de vista de partición: que lo que cambie junto que vaya junto; que lo que se publica junto que vaya junto, etcétera.
Otro tema fundamental cuando hablamos de componentes (.jar en Java por ejemplo) son las dependencias entre ellos: quién depende de quién; si hay ciclos cómo romperlos o de un concepto muy interesante: “la estabilidad” de un componente, basado en las dependencias que tienen con él y las dependencias que ese componente tiene con otros. Me han resultado llamativas algunas observaciones por su sencillez, algunas como por ejemplo: “si quieres que un componente sea estable, haz que muchos dependan de él, así cuando se altere, tocará cambiar muchas dependencias y esto será una barrera para hacer el cambio”.
Termina con una serie de métricas sobre la abstracción de los componentes y su estabilidad para determinar las interfaces y clases abstractas que poseen y su relación con la estabilidad, entendida como ratio entre clases de las que dependen y clases que dependen de ellas. Así traza un mapa bidimensional que permite clasificar los componentes en estas dos dimensiones. Desconozco si es algo inventado para este libro o hay métricas similares… quizá en algún análisis de Sonarqube no desentone.
Parte 5: arquitectura
La parte más extensa (140 páginas) e importante del libro: la arquitectura. Comienza definiendo qué entiende por arquitectura, desde diferentes puntos de vista: despliegue, mantenimiento, operaciones, independencia. También habla de la labor del arquitecto y su perfil como persona mucho más cercana al código de lo que suele ser tradicional.
Continúa analizando temas básicos de la arquitectura como la búsqueda de la independencia en el desarrollo, entre casos de uso, desacoplamiento entre capas, o duplicidades. En los siguientes capítulos trata de las fronteras o bordes que delimitan las partes en las que dividir la arquitectura y cómo se cruzan desde el punto de vista técnico: comunicación de hilos, procesos o servicios.
Otro de los puntos interesantes es la presentación de su modelo de “Clean Architecture”, basado en los principios tratados en el libro y compartido por otras arquitecturas que se están poniendo de moda como la arquitectura hexagonal de Alistair Cockburn. Te sonarán conceptos como entidades, controladores, presentadores, interfaces externas… aglutinadas en forma de círculos concéntricos.
También habla de temas misceláneos como el modelado (desacoplado) de las reglas de negocio o la expresividad de la arquitectura: si al observarla “grita” el cometido del software; o el tamaño de los servicios, haciendo una crítica al “hype” de los microservicios y su importancia en el diseño (lleno de sentido común bajo mi punto de vista). Finaliza hablando del impacto de los test y de arquitecturas embebidas.
Parte 6: detalles
Finaliza el libro como tal con esta sexta parte mucho más corta en la que se encarga de relativizar el impacto de agentes externos sobre la importancia de la arquitectura. Es común que las aplicaciones Web o que estén basadas en base de datos tenga una arquitectura similar, es decir, ésta no “grita” de qué va al observar sus diagramas. En esta parte del libro critica el impacto de frameworks, bases de datos y web sobre el diseño arquitectónico correcto.
¿Quién no ha diseñado primero la base de datos del dominio y sobre ella ha construido toda la aplicación? Esto es incorrecto: según una arquitectura limpia (clean architecture), la base de datos es un elemento externo que nos sirve para almacenar información, pero debemos estar listos para cambiarla en cualquier momento. Lo mismo ocurre con los frameworks, que nos ofrecen “casarnos” con ellos, quedando vendidos a su devenir por el típico alto acoplamiento, marcando desde fuera el diseño y ritmo de la arquitectura.
Finaliza el libro con el “missing chapter”, por Simon Brown (autor del C4Model por ejemplo). En él hace una síntesis de cómo organizar una aplicación por paquetes dependiendo de las opciones de arquitectura. Me ha resultado especialmente útil poder ver sobre ejemplos reales de organización lo que expone Uncle Bob en el resto del libro sobre establecer los bordes de la arquitectura en alternativas como capas, características, componentes o arquitectura de puertos y adaptadores (hexagonal o clean architecture). Es un buen capítulo para cerrar el libro.
En realidad no lo cierra. Uncle Bob incluye 50 páginas finales sobre “Arqueología de arquitectura” en el que da rienda suelta a sus recuerdos de más de 40 años en el negocio, contando la evolución de los sistemas y sus arquitecturas. Es un texto curioso, pero no compraría el libro por esta parte… Parece que se ha “engordado” un poco el libro para que fuera “vendible”.
* Un offtopic: quiero advertirte para que no te lleves una sorpresa: en realidad es un libro corto en el que hay signos evidentes de “relleno”: muchos capítulos (34) cada uno con un dibujo a página completa con ninguna utilidad, más allá de la de ocupar 34 páginas que podían haberse ahorrado (más sus correspondientes contrapáginas anteriores para comenzar en página par). También tiene bastantes anécdotas de “abuelo cebolleta” de relleno que sí es cierto que ayudan a ilustrar las explicaciones, pero seguramente excesivas. Y además tuvo un retraso más que evidente: podía pre-encargarse en Amazon un año antes de su salida, y tuvo retrasos durante meses y meses (eran motivo de mofa entre mis compañeros las 4 o 5 veces que recibimos el correo de Amazon indicando que la entrega se retrasaba 2 o 3 meses más). Sin tener conocimiento de los detalles parece un contenido un poco “forzado” para ser un libro del tamaño adecuado que queda bien la estantería. Se podría haber contado lo mismo en 150 páginas perfectamente, aunque claro, no sería un libro «serio».
4. Conclusiones
Es un libro escrito por uno de los referentes del “buen” desarrollo hoy en día, por lo que siempre es interesante escuchar sus opiniones, máxime cuando Uncle Bob no suele tener reparos al expresarlas. Además de referente es una persona con más de 40 años de experiencia, y casi 30 dedicado a la consultoría, lo que le da una visión que pocos profesionales tienen. Por tanto sí me parece que debe ser leído.
Me gusta especialmente la visión tan elevada que propone, de haber visto (y seguir tocando) mucho código en muchas situaciones diferentes, lo que en este libro se ha traducido en una visión muy elevada y esencial sobre conceptos generales. Por tanto no esperes ejemplos detallados de comunicación en una arquitectura de microservicios, muy al contrario: expone que usar microservicios es una forma más de implementar la comunicación de módulos y no debería afectar gravemente a la arquitectura, por poner un ejemplo claro.
Si quieres soluciones concretas no es tu libro, para eso hay otros más detallados llenos de patrones. Tampoco creo que aprendas demasiado… tal y como sucede con Clean Code por ejemplo: todos sabemos escribir variables y funciones, y sabíamos que debían ser nombradas de forma adecuada, pero fue Clean Code el que nos ayudó a seguir una senda para hacer un código más legible sin pensar que éramos los únicos locos que lo hacíamos así. Igual sucede con Clean Architecture: no creo que aprendas a manejar las dependencias de una arquitectura de componentes, pero sí te ayudará a repensar y plantear un poco mejor las cosas.
En definitiva, si bien puede saber a poco si buscas el libro de arquitectura definitivo, me parece un libro que deberías leer porque ayuda a reflexionar y a afianzar conceptos y que permite “evangelizar” sobre la importancia de la arquitectura para hacer software de alta calidad.
Aquí te dejo el enlace por si lo quieres comprar en Amazon:
Buen aporte
gracias buen aporte