Qué es la arquitectura de software
Seguí leyendo
Enterate del próximo post
Un mail cuando publico algo nuevo. Sin spam y te podés dar de baja cuando quieras.
Un mail cuando publico algo nuevo. Sin spam y te podés dar de baja cuando quieras.
Casi todo sistema tiene una arquitectura, la haya pensado alguien o no. Cada vez que se escribe código se toman decisiones, y algunas de ellas quedan tan metidas en el resto del sistema que cambiarlas después cuesta semanas en vez de minutos. La diferencia entre un sistema con arquitectura pensada y uno sin ella no es que el segundo carezca de arquitectura: es que en el segundo esas decisiones las tomó el primer código que se escribió, sin que nadie las eligiera a propósito. Esta serie trata de cómo tomar esas decisiones a propósito, cómo modelar el problema antes de tomarlas y cómo dejarlas escritas junto con lo que cuestan.
No hay una definición única de arquitectura de software, y las que conviven no se contradicen: miran el mismo objeto desde lugares distintos.
La más citada en la literatura académica viene de Len Bass, Paul Clements y Rick Kazman, en Software Architecture in Practice: la arquitectura de un sistema es el conjunto de estructuras que hacen falta para razonar sobre él, formadas por elementos de software, las relaciones entre ellos y las propiedades de ambos. Es una definición útil porque obliga a hablar en plural. Un sistema no tiene una estructura sino varias a la vez: cómo se divide el código en módulos, qué procesos corren y cómo se comunican, en qué máquinas se despliega cada cosa. Ninguna de esas vistas alcanza sola.
La otra definición influyente es más corta y más incómoda. Martin Fowler, en su artículo Who Needs an Architect? (2003), recoge dos formulaciones de Ralph Johnson: la arquitectura son las decisiones que se desearía poder tomar bien desde el principio de un proyecto, y también, dicho de forma más directa, lo importante, sea lo que sea. La segunda frase suena a evasiva, pero es precisa. Admite que no existe una lista fija de temas que sean arquitectura en todos los sistemas, y desplaza la pregunta desde el tema de una decisión hacia su consecuencia.
Esta serie toma esa segunda línea como eje y la vuelve operativa: arquitectura es el subconjunto de decisiones de un sistema cuyo costo de cambio es alto. Por eso conviene pensarlas antes de que el código las tome solo, y por eso conviene escribirlas.
Esa definición resuelve de paso la vieja pregunta de dónde termina la arquitectura y dónde empieza el diseño. La frontera no es de tamaño ni de nivel de abstracción. El nombre de una variable, el orden de dos parámetros o el color de un botón son decisiones de diseño porque se cambian en minutos y el cambio no arrastra nada. La forma en que se representa el dinero en todo el sistema, si el sistema es un proceso o varios, o en qué momento una compra pasa a ser definitiva son decisiones de arquitectura, aunque ninguna parezca grandiosa, porque cambiarlas obliga a tocar muchas partes a la vez, a migrar datos o a renegociar con alguien de afuera.
La definición tiene un costo y conviene decirlo desde el principio: es relativa. Lo que es caro de cambiar en un sistema puede ser barato en otro, así que no hay forma de saber si una decisión es arquitectura sin conocer el sistema concreto. Eso deja afuera cualquier atajo del tipo "la base de datos siempre es arquitectura" o "los patrones de diseño nunca lo son". A cambio, obliga a hacer la pregunta correcta en cada caso: si esto resultara equivocado dentro de un año, cuánto costaría corregirlo.
Todos los posts de esta serie trabajan sobre el mismo sistema: la tienda online de Alfar, un taller de cerámica artesanal que vende tazas, platos y macetas hechos a mano. Hoy vende por mensajes: una persona pregunta por una pieza, el taller confirma que está, la persona transfiere y el taller despacha. El pedido del taller es simple de enunciar: que se pueda comprar desde la web.
El detalle que vuelve interesante a este dominio está en el producto mismo. Buena parte de lo que vende el taller son piezas únicas, o series de tres o cuatro unidades. Cuando el taller anuncia una tanda nueva en redes sociales, varias personas entran a la vez a mirar las mismas piezas, y dos de ellas pueden querer la misma taza en el mismo minuto.
Por mensajes, ese caso se resuelve solo: gana quien escribe primero, y el taller lo decide a mano. En una tienda web, alguien tiene que decidir de antemano en qué momento una pieza deja de estar disponible para los demás. Esa decisión suele no aparecer en ningún pedido ni en ninguna reunión. Aparece cuando se escribe la primera versión del código de compra, y la toma quien lo escribe, casi siempre de la forma más directa: descontar la pieza del stock cuando el pago se confirma.
Esa decisión es arquitectura según la definición de arriba, aunque no mencione ninguna tecnología. Si más adelante hubiera que cambiarla, cambiarían los estados por los que pasa un pedido, lo que el stock sabe de cada pieza, la conversación con la pasarela de pagos, los mensajes que recibe quien compra y los datos que ya estén guardados. Es exactamente el tipo de decisión que conviene tomar a propósito.
El repositorio de la tienda arranca con un archivo de decisiones, y esta es su primera entrada. Por ahora es prosa suelta: más adelante la serie le da a cada entrada una forma fija, y esta primera se va a convertir a esa forma sin cambiarle el contenido.
# Decisiones de la Tienda Alfar
## 1. En qué momento se aparta una pieza
Una pieza se aparta para quien inicia el pago, no para quien lo confirma.
Mientras está apartada, nadie más puede comprarla. Si el pago no se
confirma dentro de un plazo, la pieza vuelve a estar disponible.
El plazo todavía no está decidido.
Lo que se paga: una pieza puede quedar bloqueada durante ese plazo por
una compra que no se completa.La línea menos obvia es la que admite que el plazo no está decidido. Habría sido fácil escribir un número, quince minutos o media hora, y la entrada habría parecido más completa. Pero ningún número tiene todavía un motivo: depende de cuánto tarda de verdad la pasarela en confirmar un pago y de cuánta gente entra la noche de una tanda nueva, dos datos que la tienda aún no tiene. Dejar el plazo abierto de forma explícita separa lo que ya se decidió (apartar al iniciar el pago) de lo que todavía falta decidir, y evita que un número elegido al pasar termine tratado como si hubiera sido pensado.
La alternativa descartada es la que el código habría tomado solo: no apartar nada y descontar la pieza cuando el pago se confirma. Es más simple, porque no hace falta ningún plazo ni nada que libere piezas con el paso del tiempo. En una tienda con stock abundante sería la opción razonable, porque vender una unidad de más sería raro y barato de corregir.
En Alfar el caso raro es el caso central. Con piezas únicas, descontar al confirmar el pago significa que dos personas pueden pagar la misma taza, y una de las dos recibe después un mensaje avisando que la pieza ya no existe y que el dinero se devuelve. Para un taller chico que vende por su trato cercano, ese mensaje cuesta más que cualquier complejidad técnica.
La opción elegida no es gratis. Una persona que entra al pago y abandona deja la pieza bloqueada durante el plazo, y la noche de una tanda nueva eso puede significar piezas que figuran como no disponibles sin que nadie las esté comprando. Además, el sistema necesita algo que libere las piezas cuando el plazo vence, una pieza móvil que la otra opción no tenía.
La entrada deja escrita también la condición bajo la que convendría revertirla: si el taller empezara a vender series largas con muchas unidades por pieza, la sobreventa pasaría a ser rara y barata, y apartar al confirmar el pago volvería a ser la opción más sensata. Una decisión de arquitectura escrita con su costo y con la condición que la invalidaría no es una regla fija: es un compromiso que se puede revisar cuando cambian los datos que lo justificaron.
Lo que cambia al escribirla no es la decisión en sí, que alguien habría tomado de todos modos. Cambia que ahora se puede discutir antes de que exista el código, que quien llegue al proyecto dentro de seis meses sabe por qué la tienda se comporta así, y que el día en que el taller cambie su forma de producir hay un lugar donde mirar qué decisiones dependían de la forma anterior.
La arquitectura de un sistema son las decisiones caras de cambiar. Si nadie las toma a propósito, las toma el primer código que se escribe, y quedan escondidas en él.
Decidir en qué momento se aparta una pieza no necesitó ningún diagrama ni ninguna tecnología. Pero para decidir sobre algo más grande que una sola regla, hace falta primero una forma de mirar el sistema entero sin perderse en sus detalles. El próximo post trata de eso: qué es un modelo, por qué todo modelo deja cosas afuera a propósito, y cómo se elige qué dejar afuera.