Estilos arquitectónicos I: monolitos y diseños modulares

Te damos la bienvenida al Capítulo 5: Estilos arquitectónicos, primera parte, monolitos y diseños modulares. La mayor parte del software, incluidos algunos de los productos más grandes y exitosos, se ejecuta como una única aplicación desplegable. Este capítulo explica cómo deben estructurarse por dentro esas aplicaciones, y cuándo una sola aplicación es la respuesta correcta.

Los Capítulos 3 y 4 te dieron los principios de una buena estructura y las herramientas para describirla. Este capítulo y el siguiente convierten esos principios en las formas recurrentes que adoptan los sistemas reales. Conocer los estilos principales te permite partir de una forma que se sabe que funciona para un conjunto dado de cualidades, explicarla en una frase y reconocer pronto cuándo un sistema se está alejando de ella. Este capítulo trata los estilos en los que toda la aplicación es una sola unidad de despliegue: una compilación, un lanzamiento, normalmente una base de datos. Eso no hace que los monolitos sean primitivos. Que trabajar en un monolito sea un placer o un suplicio depende casi por completo de cómo esté dividido por dentro.

El capítulo está dirigido a desarrolladores y arquitectos que diseñan o mantienen aplicaciones de negocio y quieren elegir y hacer cumplir una estructura de forma deliberada. Se apoya en los Capítulos 3 y 4, en especial en la modularidad, el acoplamiento y la cohesión, las dependencias y la organización en capas, y el modelo C4. Los atributos de calidad del Capítulo 2 se usan a lo largo de todo el capítulo. Y conduce al Capítulo 6, que lleva las mismas preguntas a través de una red, donde las cosas se complican. Un monolito evita los fallos de red, las caídas parciales y los problemas de consistencia de los sistemas distribuidos. De ellos se ocupa el Capítulo 6.

Primero, una definición. Un estilo arquitectónico es un conjunto con nombre de restricciones sobre los tipos de partes que tiene un sistema y sobre cómo pueden conectarse. Las restricciones son lo importante. Prohíbe, por ejemplo, que un módulo de negocio toque las tablas de otro, y obtendrás beneficios predecibles, a un precio predecible.

El capítulo tiene ocho secciones. La Sección cinco punto uno establece el vocabulario que se usa para cada estilo de los Capítulos 5 y 6: estilos, patrones, tácticas y arquitecturas de referencia. Explica la diferencia entre el particionamiento técnico, por capa, y el particionamiento por dominio, por capacidad de negocio. Y presenta el cuanto de arquitectura: una parte desplegable de forma independiente, datos incluidos, a la que se aplica un mismo conjunto de cualidades.

Veamos por qué importa el particionamiento. Supón que una empresa de reparto de comida permite a los clientes añadir una propina para el repartidor. Con el particionamiento técnico, ese único cambio toca la capa de presentación, la lógica de negocio y la capa de persistencia. Con el particionamiento por dominio, el mismo cambio cae casi por completo en el módulo de reparto, que por dentro puede seguir organizado en capas. 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. Y permite que cada equipo sea dueño de una capacidad de negocio de principio a fin.

Las Secciones cinco punto dos a cinco punto cinco describen cuatro estilos con el mismo formato, con un diagrama, un ejemplo, una tabla de características, cuándo usarlo y cómo hacerlo cumplir en el código. La arquitectura en capas es la conocida pila de capas de presentación, de negocio y de persistencia. El monolito modular divide una sola aplicación desplegable por dominio de negocio, con interfaces de módulo explícitas y una propiedad clara de los datos, ilustrado con la experiencia de Shopify. Tuberías y filtros organiza el procesamiento como una cadena de pasos independientes, desde las tuberías de Unix hasta los pipelines de datos. Y el microkernel construye un núcleo mínimo que los plug-ins amplían, como en las herramientas de desarrollo, los navegadores y los motores de reglas.

Este diagrama de la Sección cinco punto tres muestra un monolito modular por dentro. El límite discontinuo es una sola unidad de despliegue: la aplicación de reparto de comida. Cada módulo, aquí Pedidos y Pagos, tiene una pequeña API pública. Pedidos solo puede usar Pagos llamando a esa API. Todo lo demás de un módulo es interno. Está prohibido acceder desde las partes internas de un módulo a las de otro. Y cada módulo es dueño de su propio esquema, sin joins entre esquemas. Respeta estas reglas, y cualquier módulo podrá extraerse más adelante a un servicio con un esfuerzo moderado.

La Sección cinco punto seis trata las arquitecturas hexagonal, de cebolla y limpia. Ponen la lógica de negocio en el centro y hacen que las bases de datos, las interfaces de usuario y los servicios externos dependan de ella, nunca al revés. La Sección cinco punto siete, sobre el diseño estratégico guiado por el dominio, aporta el método para encontrar buenos límites: subdominios, contextos delimitados y las relaciones entre ellos en un mapa de contextos. Por último, la Sección cinco punto ocho se pregunta cuándo un monolito es la respuesta correcta, hasta dónde puede escalar y qué señales indican que ha llegado el momento de dividirlo. Termina con una guía de decisión y una tabla comparativa de todos los estilos del capítulo.

Si recuerdas una sola cosa, que sea esta: los límites dentro de un sistema importan más que los límites entre unidades de despliegue. Un conjunto de servicios que comparten una base de datos y llaman a las partes internas de los demás sigue siendo un único sistema enmarañado, ahora con fallos de red añadidos. De ahí se derivan dos hábitos. Primero, elige el estilo más sencillo cuyas características satisfagan los requisitos arquitectónicamente significativos del sistema, y registra la elección y sus compromisos en un registro de decisiones. Segundo, haz cumplir las reglas del estilo con pruebas de arquitectura en la compilación, porque todo estilo se erosiona cuando sus restricciones solo viven en la cabeza de las personas.

Lee primero la Sección cinco punto uno, porque todas las secciones posteriores usan su vocabulario. Después, puedes seguir los estilos en orden o ir directamente al que necesites. Leer el capítulo lleva unas tres horas. Sigue la plataforma de reparto de comida a medida que recorre el capítulo. Comparar los estilos sobre un único sistema conocido es mucho más fácil que sobre ejemplos de juguete sin relación entre sí. Cada sección termina con unas cuantas preguntas de autoevaluación. Respóndelos mentalmente antes de mirar. Cuando estés listo, haz la prueba opcional del capítulo: veinte preguntas de opción múltiple y dos respuestas escritas, en unos cuarenta y cinco minutos. La nota de aprobado es el ochenta por ciento.

Ese es el mapa del Capítulo 5. Empieza por la Sección cinco punto uno, donde establecemos el vocabulario de estilos, patrones y tácticas en el que se apoyan los dos capítulos siguientes. Nos vemos allí.