Estilos, patrones y tácticas arquitectónicos

Por qué los arquitectos ponen nombre a las formas

La mayoría de los sistemas no se diseñan desde cero. Los arquitectos con experiencia reconocen que un problema nuevo se parece a otro que ya han visto y recurren a una forma que se sabe que funciona: unas pocas capas para una aplicación de negocio sencilla, una cadena de pasos de procesamiento para un flujo de datos, un núcleo con plug-ins para un producto que los clientes amplían. Poner nombre a esas formas da a un equipo un vocabulario común. Decir es un monolito modular con comunicación basada en eventos entre módulos transmite en una decena de palabras lo que de otro modo llevaría una página de diagramas, y trae consigo un conjunto de conocimientos sobre lo que suele salir bien y mal.

David Garlan y Mary Shaw le dieron una base sólida en An Introduction to Software Architecture (informe técnico de Carnegie Mellon, 1994) y en su libro Software Architecture: Perspectives on an Emerging Discipline (1996). Describieron un estilo arquitectónico como un vocabulario de tipos de componentes y de conectores junto con un conjunto de restricciones sobre cómo pueden combinarse. Tuberías y filtros, por ejemplo, tiene un tipo de componente (un filtro que transforma datos) y un tipo de conector (una tubería que los transporta en un solo sentido), y obliga a que los filtros no compartan estado ni sepan quiénes son sus vecinos. Roy Fielding, cuya tesis doctoral (2000) definió REST como un estilo, lo expresó de forma aún más tajante: un estilo es un conjunto coordinado de restricciones, y son las restricciones las que producen las propiedades. Prohíbe que los filtros compartan estado y obtendrás filtros que se pueden probar, reutilizar y reorganizar de forma independiente; no es suerte, es una consecuencia de la regla.

Esta es la forma más útil de leer cada estilo de este capítulo y del siguiente. Un estilo no es un dibujo que copiar. Es un conjunto de reglas que te comprometes a seguir, elegidas porque seguirlas te da unas características de arquitectura concretas, los atributos de calidad del Capítulo 2, a cambio de un precio. Un equipo que adopta el vocabulario de un estilo pero no sus reglas paga el precio sin obtener los beneficios.

Estilos, patrones, tácticas y arquitecturas de referencia

Se usan cuatro términos relacionados, a menudo sin mucha precisión, para referirse al conocimiento de diseño reutilizable. Se diferencian sobre todo en su alcance y en cuánto prescriben.

Un patrón arquitectónico describe una solución probada a un problema estructural recurrente en un contexto dado. La idea de los patrones procede del arquitecto de edificios Christopher Alexander y llegó al software a través de los patrones de diseño de Gamma, Helm, Johnson y Vlissides (1994), que trabajan a la escala de unas pocas clases. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns, de Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y Michael Stal (1996), normalmente llamado POSA, catalogó patrones a la escala de sistemas completos: Capas (Layers), Tuberías y filtros (Pipes and Filters) y Pizarra (Blackboard), agrupados como el paso del barro a la estructura; Broker para sistemas distribuidos; Modelo-Vista-Controlador y Presentación-Abstracción-Control para sistemas interactivos; y Microkernel y Reflexión (Reflection) para sistemas adaptables. Cada patrón de POSA se describe con su contexto, problema, fuerzas y solución, junto con sus consecuencias, lo que hace explícitos los compromisos.

Una táctica, en el sentido que le dan Len Bass, Paul Clements y Rick Kazman en Software Architecture in Practice, es algo más pequeño: una decisión de diseño que influye en la respuesta de un atributo de calidad, como añadir un heartbeat para detectar un servidor caído o una caché para reducir la latencia. La Sección 2.6 usó tácticas de modificabilidad como el encapsulamiento y el uso de un intermediario. Los patrones agrupan varias tácticas: el patrón Capas combina el encapsulamiento, la restricción de dependencias y el uso de un intermediario.

Una arquitectura de referencia es una plantilla para todo un dominio o una plataforma: nombra los bloques de construcción típicos y cómo se conectan, para que los proyectos la adapten en lugar de partir de una página en blanco. AUTOSAR, la arquitectura de software en capas que se usa para las unidades de control electrónico de los automóviles, es un ejemplo conocido; los centros de arquitectura que publican los proveedores de nube ofrecen muchos otros más pequeños. Una arquitectura de referencia suele construirse a partir de varios estilos y patrones a la vez.

Los profesionales no se ponen de acuerdo sobre dónde está la frontera entre estilo y patrón. POSA considera Capas (Layers) un patrón; Garlan y Shaw llaman estilo a los sistemas en capas; Mark Richards y Neal Ford, en Fundamentals of Software Architecture, reservan estilo para la topología general de un sistema y patrón para estructuras reutilizables de nivel más bajo que pueden aparecer dentro de muchos estilos. Este curso sigue el uso habitual: estilo para la forma general de un sistema o de una gran parte de él, patrón para una solución reutilizable que puede situarse en cualquier nivel. No gastes energía en la frontera; gástala en las restricciones y sus consecuencias.

Dos formas de dividir un sistema: particionamiento técnico o particionamiento por dominio

La primera decisión estructural en cualquier estilo es cómo dividir el sistema en el nivel superior. Hay dos respuestas básicas. El particionamiento técnico agrupa el código por función técnica: todo lo relativo a la interfaz de usuario en un lugar, todas las reglas de negocio en otro, todo el acceso a la base de datos en un tercero. El particionamiento por dominio agrupa el código por capacidad de negocio: todo lo relativo a los pedidos en un lugar, los pagos en otro, las entregas en un tercero, cada uno con la interfaz de usuario, la lógica y el acceso a datos que necesite.

La diferencia se nota en cuanto cambia una funcionalidad. Supón que una empresa de reparto de comida permite a los clientes añadir una propina para el repartidor. En un sistema con particionamiento técnico, ese cambio necesita un campo nuevo en una pantalla (presentación), una regla nueva para los límites y el abono de las propinas (lógica de negocio) y una columna y una consulta nuevas (persistencia): tres partes, a menudo a cargo de tres personas o equipos distintos. En un sistema con particionamiento por dominio, el mismo cambio cae casi por completo en el módulo de reparto. La mayoría de las solicitudes de cambio del negocio se formulan en términos del dominio, así que el particionamiento por dominio tiende a mantener un cambio en un solo lugar. El particionamiento técnico mantiene en un solo lugar un cambio técnico, como sustituir la biblioteca de acceso a la base de datos, pero esos cambios son menos frecuentes.

La elección también da forma a la organización. Según la ley de Conway, un sistema con particionamiento técnico tiende a construirlo un equipo de frontend, un equipo de backend y un equipo de base de datos, y cada funcionalidad necesita un traspaso entre ellos. Un sistema con particionamiento por dominio puede construirse con equipos que sean dueños, cada uno, de una capacidad de negocio de principio a fin. Martin Fowler hizo la misma recomendación en 2015: las capas de presentación, dominio y datos son una buena manera de organizar una pieza pequeña de software, pero el nivel superior de un sistema más grande debería dividirse en módulos orientados al dominio, cada uno organizado en capas por dentro si eso ayuda.

Ninguna de las dos es incorrecta. El particionamiento técnico es sencillo, conocido y está respaldado por la estructura de carpetas predeterminada de casi cualquier framework web, y encaja con sistemas pequeños en los que un solo equipo lo hace todo. El particionamiento por dominio exige más reflexión al principio, porque alguien tiene que encontrar buenos límites de dominio (el tema de la Sección 5.7), pero escala mejor con el tamaño del sistema y el número de equipos.

Estilos monolíticos y distribuidos

La segunda distinción de nivel superior tiene que ver con el despliegue. Una unidad de despliegue es lo que se compila, se lanza y se arranca como una sola pieza: un único ejecutable, una imagen de contenedor, un archivo web. En una arquitectura monolítica, toda la aplicación es una sola unidad de despliegue, normalmente con una sola base de datos. Puede ejecutarse como muchas copias idénticas detrás de un balanceador de carga, pero cada copia contiene todo el código, y lanzar cualquier cambio significa lanzarlo todo. En una arquitectura distribuida, el sistema está formado por varias unidades de despliegue que cooperan enviándose mensajes a través de una red, y cada una puede lanzarse y escalarse por separado.

Dos aclaraciones evitan mucha confusión. Primera: monolito describe el despliegue, no la calidad. Un monolito puede ser maravillosamente modular o una gran bola de barro (big ball of mud, el nombre que Brian Foote y Joseph Yoder dieron a un sistema sin una estructura discernible), y lo mismo vale para un sistema distribuido: muchos equipos han aprendido que dividir una bola de barro en servicios da una bola de barro distribuida, que es peor. Segunda: ser distribuido no es una mejora gratuita. Cualquier llamada que cruza una red puede ser lenta, fallar a medias o llegar dos veces, los datos ya no pueden modificarse en una única transacción local, y el sistema necesita monitorización, automatización del despliegue y capacidades de guardia de las que un monolito puede prescindir. El Capítulo 6 trata esos costos en detalle. Este capítulo trata los estilos que los evitan: todo se ejecuta en una sola unidad de despliegue, y la arquitectura reside en cómo se organiza el código dentro de ella.

El cuanto de arquitectura

Monolítico frente a distribuido es una primera división útil, pero demasiado gruesa para las decisiones reales. Neal Ford, Rebecca Parsons y Patrick Kua introdujeron una idea más precisa en Building Evolutionary Architectures (2017), que Ford, Richards, Sadalage y Dehghani refinaron en Software Architecture: The Hard Parts (2021): el cuanto de arquitectura (architecture quantum). Un cuanto es una parte del sistema que puede desplegarse de forma independiente, tiene alta cohesión funcional (hace un trabajo coherente para el negocio) e incluye todo lo que necesita para funcionar, en particular su base de datos. La definición posterior añade que las partes de un cuanto están acopladas estáticamente (comparten código, esquemas o infraestructura que deben desplegarse juntos) y que las llamadas síncronas unen los cuantos operativamente mientras dura la llamada.

¿Por qué importa esto? Porque las características de arquitectura se aplican por cuanto. Un cuanto se escala, se despliega, se protege y se recupera como un todo, así que tiene un único nivel de escalabilidad, un único nivel de disponibilidad y una única cadencia de lanzamientos. Si dos partes de un sistema necesitan características muy distintas, por ejemplo un flujo de posiciones de repartidores que debe absorber miles de actualizaciones por segundo y un proceso mensual de facturación a restaurantes, solo pueden obtenerlas estando en cuantos distintos. A la inversa, dividir el código en varios servicios no crea varios cuantos si siguen compartiendo una base de datos: ninguno puede cambiar el esquema ni restaurarse por sí solo, así que se mantienen o caen juntos. Un monolito es, por definición, un solo cuanto.

Cómo leer las secciones de estilos que siguen

Las Secciones 5.2 a 5.5 y la mayor parte del Capítulo 6 describen un estilo cada una, siempre en el mismo orden, para que los estilos se puedan comparar: una definición y de dónde viene el estilo; un diagrama; cómo funciona; un sistema de ejemplo concreto; una tabla que valora sus características principales; cuándo usarlo y cuándo no; los antipatrones habituales; y cómo hacerlo cumplir en el código, porque un estilo que no se comprueba se erosiona, como describió la Sección 1.7.

Las valoraciones de las características (Baja, Media, Alta, cada una con un motivo) siguen el enfoque de las comparaciones de estilos de Richards y Ford, pero son juicios propios de este curso. Léelas como relativas y típicas: comparan los estilos tal como se construyen normalmente, por un equipo competente, para un sistema de negocio típico. Un equipo disciplinado puede hacer un monolito en capas que se despliegue muchas veces al día, y uno descuidado puede construir microservicios que no se pueden desplegar en absoluto. Las valoraciones te dicen dónde ayuda el estilo y dónde tendrás que trabajar en su contra.

Dos secciones de este capítulo no tratan de estilos de despliegue. Las arquitecturas hexagonal, de cebolla y limpia (Sección 5.6) describen cómo organizar el interior de una aplicación o de un servicio para que la lógica de negocio no dependa de la tecnología. El diseño guiado por el dominio (Sección 5.7) es una forma de encontrar los límites de dominio en los que se apoyan los monolitos modulares y los microservicios. Ambos se aplican igual dentro de un monolito que de un sistema distribuido.

Los estilos se combinan, y no son objetivos

Los sistemas reales son híbridos. Un monolito modular puede estar organizado en capas dentro de cada módulo; uno de sus módulos puede ejecutar un proceso nocturno de tuberías y filtros; un microservicio puede construirse con estilo hexagonal; un sistema dirigido por eventos puede usar un microkernel para que los clientes añadan sus propias reglas. Nombrar el estilo de cada parte sigue siendo útil, porque así cada parte hereda un conjunto conocido de reglas y compromisos.

El error habitual es tratar un estilo como un fin en sí mismo: nos estamos pasando a microservicios como estrategia, en lugar de como medio para lograr una cualidad declarada, como el despliegue independiente para doce equipos. Parte de los requisitos arquitectónicamente significativos del Capítulo 2, elige el estilo más sencillo cuyas características los satisfagan, deja constancia de la elección en un registro de decisiones y haz cumplir sus reglas. La Sección 5.8 ofrece una guía de decisión para los estilos de este capítulo.