La parte 1 cerró con una frase que ahora me parece una trampa: los componentes que salen de una descomposición por volatilidad «pueden verse como opciones». Es verdad, y es insuficiente. Una opción se compra por el derecho a algo bueno. Un módulo que encapsula una volatilidad se compra por miedo a algo malo. Eso no es una opción: es un seguro.
La distinción no es semántica. Gregor Hohpe lleva años explicando que la arquitectura vende opciones, y tiene razón en el nivel en el que lo dice: aplazar una decisión tiene valor medible. Pero cuando bajas de la estrategia al módulo, la analogía financiera correcta cambia y con ella cambia la pregunta. Una opción se valora por lo que puedes ganar. Una póliza se cotiza por lo que puedes perder y, sobre todo, por lo que cuesta mantenerla viva mientras no pasa nada.
Ese es el hueco que dejó la parte 1, y que deja casi todo lo que se escribe sobre esto, incluido Löwy: te explica cómo encontrar la volatilidad, no cuál de las que encuentres merece un módulo. Toda arquitectura tiene veinte volatilidades identificables y presupuesto para tres.
La póliza que suscribes sin leerla
Cada vez que encapsulas una volatilidad firmas un contrato con estas tres partes:
- La prima. Lo que pagas cada mes, pase lo que pase. En arquitectura es la indirección: la interfaz que hay que mantener, el mapeo que se escribe dos veces, la capacidad nativa que ya no puedes usar. Martin Fowler lo llamó coste de acarreo: la complejidad que la pieza añade encarece todas las features que vengan después, no solo la que la justificó.
- El siniestro. El cambio, si llega: el proveedor que sube el precio, la regulación nueva, el motor que hay que sustituir.
- La indemnización. Lo que te ahorras cuando el siniestro llega. Ojo: no es el coste del cambio, es la diferencia entre hacerlo con póliza y sin ella.
Las tres se pueden estimar y ninguna se estima nunca en una revisión de diseño. Lo que se discute allí es si la volatilidad es real, que es la pregunta fácil y cuya respuesta casi siempre es sí.
¿Por qué nadie cotiza la prima?
Porque la industria heredó la mitad del criterio original. Cuando Parnas fijó en 1972 el criterio para descomponer un sistema en módulos no dijo «esconde lo que cambia»: dijo esconde lo que es probable que cambie. Ahí dentro hay una probabilidad, y una probabilidad es un número entre cero y uno. Cincuenta años después el criterio circula sin el número, convertido en absoluto: esconder es bueno, luego esconde todo.
Fowler es la otra mitad de la respuesta. Su artículo sobre YAGNI es la mejor descripción que conozco de lo que cuesta construir para un futuro que no llega, y a continuación se saca del alcance a sí mismo: aclara que YAGNI no aplica al esfuerzo de hacer el software más fácil de modificar. Eso deja nuestro caso fuera de la única herramienta que la industria usa para frenar el trabajo especulativo, porque encapsular una volatilidad es, por definición, esfuerzo para facilitar una modificación futura. Pase, adelante. Y en el mismo artículo hay otra regla que empuja en dirección contraria: YAGNI aplica siempre que añades complejidad hoy de la que no te aprovechas hasta después, y un módulo que encapsula una volatilidad que todavía no se ha movido cumple esa definición con holgura.
No creo que se contradiga. Creo que el hueco entre sus dos reglas es donde vive la arquitectura sobreasegurada, y que no se cierra con una tercera regla: se cierra con una cotización. Por cierto, el ejemplo que él eligió es una aseguradora que valora riesgos de tormenta y de piratería. El seguro estaba en el dominio del ejemplo; lo que sostengo aquí es que estaba también en la arquitectura.
Acertar con la volatilidad y perder igual
Segment contó públicamente cómo partió su monolito en un servicio por cada destino al que enviaba eventos. El diagnóstico de volatilidad era impecable: cada destino es la API de un tercero que cambia cuando quiere y falla cuando quiere, y una cola compartida hacía que el destino lento castigase a todos los demás. Encapsularon exactamente la volatilidad correcta.
Y acabaron volviendo al monolito, porque la prima crecía con el catálogo. Añadían del orden de tres destinos al mes, y cada destino traía su repositorio, su cola y su servicio, así que la carga operativa creció en línea recta con el número de pólizas suscritas.
Es la parte que se cae cuando se cita este caso como argumento contra los microservicios: no fue un error de diagnóstico, fue un error de cotización. Tenían razón sobre la volatilidad. La factura les llegó igual.
La prima no la fija el código que escribes
Aquí va la cuenta que sí cabe en una servilleta. Equipo de seis personas, horizonte de cinco años, y las mismas 48 semanas de año laboral de siempre: unas 1.440 semanas-persona de capacidad.
Póliza número uno, la más suscrita del mundo: la capa de repositorio para poder cambiar de base de datos.
- Prima: la capa prohíbe lo propio del motor, así que cada consulta se escribe contra el mínimo común denominador. Pon un 3% de sobrecoste por feature: 43 semanas-persona en cinco años.
- Probabilidad del siniestro, cambiar el motor principal en cinco años: sé generoso, un 10%.
- Coste del cambio sin póliza: 8 semanas-persona de migración.
- Indemnización esperada: 0,10 × 8 = 0,8 semanas-persona.
Cuarenta y tres contra cero coma ocho. Cincuenta y cuatro veces sobreasegurado, y el número real es peor, porque esta póliza deteriora su propia indemnización: el día de la migración no mueves el sistema que habrías construido, mueves la versión empobrecida que la capa te obligó a escribir. Es el mínimo común denominador de la multinube, a escala de módulo.
Póliza número dos: el cálculo de impuestos en un módulo.
- Probabilidad del siniestro en cinco años: 100%. Los tipos y las reglas de facturación cambian; es lo único que hacen.
- Coste del cambio sin póliza, con el cálculo repartido por cuarenta puntos de llamada: unas 3 semanas-persona cada vez, y habrá varias.
- Prima: un módulo con una función y una tabla, que no te prohíbe nada. Prácticamente cero.
Las dos cuestan lo mismo de escribir: un día de trabajo, una interfaz, unos tests. Y una es un despilfarro de 43 semanas y la otra es la mejor compra del proyecto. La diferencia no está en el código.
La prima no la fija el código que escribes, la fija lo que la encapsulación te prohíbe.
Esa es la pregunta que falta en la revisión de diseño. No «¿cuánto nos cuesta montar esto?», que es barato y por eso nadie se resiste, sino «¿qué dejamos de poder hacer mientras esto siga en pie?».
«¿Y si me toca migrar y no tengo la capa?»
Entonces pagas la migración, que era el plan. Se llama autoseguro y es lo que haces con el móvil sin pensarlo: asegurar 200 euros a cambio de 40 al año no tiene sentido, y no deja de no tenerlo porque el móvil se rompa de verdad.
Fowler concede este punto y lo explica mejor de lo que yo lo haría: las veces que YAGNI sale mal existen, son caras y se recuerdan, mientras que las veces en que ahorró trabajo no dejan cicatriz. Es sesgo de disponibilidad. Cada arquitecto tiene en la cabeza una migración que habría sido más fácil con la capa, y ninguno recuerda las once capas que no construyó.
Las pólizas tienen franquicia
Aquí la metáfora devuelve más de lo que le pedí. En los seguros nadie discute entre cobertura total y nada: se ajusta la franquicia, se cubre una parte y se retiene el resto. La encapsulación funciona igual, y casi nunca se plantea así.
Tres niveles, de más prima a menos:
- Cobertura total. Interfaz, implementación intercambiable y tests de contrato contra dos implementaciones. Prima alta, porque la interfaz define el techo de lo que puedes usar.
- Franquicia. No abstraes: acotas. Todo el SQL vive en un directorio, sin capa por encima, usando el motor a fondo. Si llega el siniestro reescribes esos archivos, y sabes cuántos son. Prima casi cero porque no te prohíbe nada, e indemnización menor que con cobertura total: para eso está la franquicia.
- Autoseguro. Nada. El siniestro se paga entero si llega, y la decisión queda escrita en el ADR junto con la probabilidad que estabas asumiendo.
Cotización de una volatilidad: prima, indemnización esperada y los tres niveles de cobertura.
Casi todas las discusiones de diseño se libran entre el primer nivel y el tercero, y el segundo gana la mayoría de las veces. El nivel intermedio incomoda porque no se puede presentar como un principio: hay que presentarlo como un número.
Donde el seguro deja de parecerse
Hohpe advierte que una metáfora se elige por la dinámica y no por la imagen: cuenta que cambió el indicador de gasolina por una alcancía cuando le señalaron que el depósito se llena rápido y se vacía despacio, y el capital político hace justo lo contrario. Así que toca decir dónde esta metáfora no coincide, y en los dos casos la arquitectura sale perdiendo en la comparación.
La prima de un seguro está fija en el contrato; la de una encapsulación crece. La pagan todas las features futuras, y cada año hay más features futuras. Firmas la prima de hoy y te la revalorizan sola.
Y no se cancela por carta. Retirar una abstracción de un sistema vivo cuesta más que no haberla puesto, porque hay que desmontarla de todos los sitios que ya la usan. Es una póliza con penalización de salida, y eso explica que las capas de repositorio sobrevivan a los equipos que las escribieron.
Hay una dinámica que sí coincide y que no fui a buscar: el riesgo moral. Con la póliza puesta se deja de vigilar. Un equipo que cree que puede cambiar de proveedor cuando quiera evalúa peor a su proveedor, igual que el asegurado aparca donde no aparcaría sin seguro. Esa parte de la factura no aparece en ninguna estimación.
Mi sugerencia
En la próxima revisión de diseño en la que alguien proponga un módulo «para poder cambiar X», pide tres números en voz alta antes de discutir el diseño:
- La probabilidad de que X cambie en el horizonte del sistema. Un número, dicho delante de todos.
- El coste del cambio sin la póliza. Imagina la refactorización completa. Suele ser bastante menor de lo que la sala cree.
- Lo que la encapsulación nos prohíbe. Esta es la que nadie estima, y es la que fija la prima.
Si el producto de los dos primeros no supera al tercero, no lo encapsules: acótalo, y escribe en el ADR la probabilidad que estás asumiendo.
Sé cómo acaba esto. Vas a suscribir la póliza igual, porque montar la interfaz es barato, queda bien en la pizarra y a nadie han despedido nunca por sobreasegurar. Hazlo. Solo te pido una cosa: escribe el número. Dentro de dos años alguien lo va a leer, y va a ser una de dos cosas: la decisión mejor documentada del proyecto, o la factura de un seguro que nunca cobraste. ;)
Referencias
On the Criteria To Be Used in Decomposing Systems into Modules — David L. Parnas, 1972
Architecture: Selling Options — Gregor Hohpe
Mighty Metaphor — Gregor Hohpe