Diseñar las costuras

Descripción

Las dos lecciones anteriores dejaron al arquitecto entre dos abismos. A un lado, el over-engineering (lección 5): preparar de más, construir flexibilidad para todo futuro imaginable, pavimentar doce carriles para un pueblo. Al otro, el under-engineering (lección 6): preparar de menos, negarse a dejar una sola costura, fijar todo en concreto y pintarse en una esquina. Esta lección —el corazón del módulo— muestra el camino entre los dos: diseñar las costuras en el punto sensato. No es un consejo cualitativo ("busca el equilibrio"); es una decisión que se calcula, porque las lecciones 3, 5 y 6 ya te dieron todas las piezas del cálculo.

La idea que lo ordena todo es una frase que hay que grabar: diseñar para el cambio no es diseñar para TODO cambio imaginable. El arquitecto que confunde las dos cosas cae en el over-engineering, porque los cambios imaginables son infinitos y prepararlos todos es imposible y ruinoso. Diseñar para el cambio, bien entendido, es construir la costura solo donde el cambio es bastante probable para que se pague sola, y diferir todo lo demás. La variable que decide no es el miedo (que empuja al over-engineering), ni la pereza (que empuja al under-engineering), sino la probabilidad del cambio, comparada con su punto de equilibrio. Esta lección ejecuta ese right-sizing sobre un portafolio de futuros de Mercado, y muestra que le gana a los dos extremos a la vez —no por poco, por mucho—.

Conexión con el módulo. Es la síntesis de las tres lecciones anteriores (esta cierra el arco: optionality → over → under → el medio). Reúne el punto de equilibrio de la lección 3 (¿vale la pena la costura?), el error del over-engineering de la 5 (no construyas para lo improbable) y el del under-engineering de la 6 (sí construye para lo probable) en un solo procedimiento ejecutable. Después de esta lección, el proyecto (lección 8) te pone a aplicarla de cero sobre un caso nuevo. Frontera con la guía hermana: aquí no clasificamos formalmente cada decisión ni escribimos el ADR; trabajamos la postura y el criterio del arquitecto que right-sizea la evolución —la mecánica de registrar y clasificar esas decisiones es architecture-decisions—.

Una analogía: el urbanista que reserva el derecho de vía —y solo el que hace falta

Vuelve por última vez al urbanista, porque los tres del módulo se juntan aquí en uno solo que hace bien su trabajo.

Recuerda a los tres. El primer urbanista (under-engineering) construyó cada metro hasta el borde, sin dejar espacio; cuando la ciudad creció, no había por dónde abrir la avenida y hubo que demoler. El segundo (over-engineering) pavimentó doce carriles y un aeropuerto para tres mil habitantes; drenó el presupuesto en infraestructura vacía. El tercero —el bueno— no hizo ninguna de las dos cosas: reservó el derecho de vía, la franja de terreno por donde, si el tráfico llega, se abrirá la avenida barato.

Pero ahora mira más de cerca lo que hace el tercer urbanista, porque su verdadera maestría no es "reservar terreno" en abstracto —es elegir dónde—. Frente al plano de la ciudad futura, no reserva derecho de vía en todas partes (eso sería el segundo urbanista, que congela media ciudad "por si acaso"). Tampoco en ninguna (el primero). Reserva la franja donde el crecimiento es probable: la avenida hacia la zona que ya se está poblando, el corredor hacia la carretera que conecta con la ciudad grande, el espacio para la línea de agua que la expansión evidente va a necesitar. Y no reserva para lo improbable: no deja terreno para un puerto marítimo (el pueblo está tierra adentro), ni para una segunda pista de aeropuerto que no vendrá. Su plano es un mapa de probabilidades: reserva donde es probable, construye lo que hace falta hoy, y deja libre el resto para que la ciudad lo use ahora.

Esa es la síntesis del módulo, y es la del arquitecto de Mercado. No deja costuras en todas partes (over-engineering) ni en ninguna (under-engineering); deja la costura donde el cambio es probable: la interfaz para extraer el catálogo (probable, el negocio crece), la abstracción del proveedor de pagos (probable, finanzas lo negocia), la frontera entre reviews y recomendaciones (probable, son dominios distintos). Y no deja costura donde el cambio es improbable: no abstrae para convertir Mercado en red social, no prepara 40 idiomas para un país, no construye el marketplace de plugins que nadie pidió. El derecho de vía se reserva para la avenida probable; el resto del terreno se deja libre. Esta lección convierte ese "donde es probable" en un cálculo, y mide cuánto le gana a los dos extremos.

Ejemplo trabajado: el right-sizing contra los dos extremos

Vamos a ejecutar la síntesis. Tomamos un portafolio de futuros posibles de Mercado, mezclando —a propósito— cambios de alta probabilidad (los que la lección 6 diría "prepara") con cambios de baja probabilidad (los que la lección 5 diría "no prepares"). Cada futuro tiene su probabilidad (p), el costo de dejar la costura hoy (seam), el de adaptarse a través de ella si la dejaste (adapt), y el de reescribir si no la dejaste (rewrite).

Comparamos tres posturas —los dos abismos y el medio—:

• rigid — el under-engineering: no construye ninguna costura. Para cada futuro paga el costo esperado de reescribir, p × rewrite.
• over_engineered — el over-engineering: construye todas las costuras. Para cada futuro paga seam + p × adapt, se justifique o no.
• right_sized — el punto sensato: construye la costura solo donde se paga sola —donde el costo de construirla (seam + p × adapt) es menor que el de no construirla (p × rewrite)— y difiere el resto. Para cada futuro elige el más barato de los dos, futuro por futuro.

La decisión de right_sized, futuro por futuro, es exactamente la comparación del punto de equilibrio de la lección 3: construye la costura si sale más barato que arriesgar la reescritura; difiere (YAGNI) si no:

# Disenar las costuras: ni over-engineering (costura para todo) ni under-engineering
# (costura para nada). El punto sensato: construir la costura SOLO donde el cambio
# es bastante probable para que la costura se pague sola; diferir el resto (YAGNI).
# Cada futuro posible de Mercado:
#   p       : probabilidad de que el cambio llegue
#   seam    : costo de construir la costura hoy
#   adapt   : costo de adaptarse DESPUES si hay costura
#   rewrite : costo de reescribir si NO hay costura
PORTFOLIO = [
    # (nombre, p, seam, adapt, rewrite)
    ("monolith_to_services",     0.90,  8000, 10000, 90000),
    ("second_payments_provider", 0.70,  4000,  5000, 40000),
    ("reviews_and_ratings",      0.50,  6000,  6000, 30000),
    ("international_currencies",  0.25,  9000,  8000, 26000),
    ("plugin_marketplace",       0.05, 20000, 15000, 40000),
    ("white_label_multitenant",  0.03, 25000, 12000, 35000),
]


def cost_build(p, seam, adapt, rewrite):
    return seam + p * adapt          # costura hoy + adaptacion esperada


def cost_defer(p, seam, adapt, rewrite):
    return p * rewrite               # sin costura: rework esperado si llega


rigid_total = over_total = right_total = 0
built, deferred = [], []
print(f"{'futuro':<28}{'p':>6}{'build':>10}{'defer':>10}   decision right-sized")
print("-" * 74)
for name, p, seam, adapt, rewrite in PORTFOLIO:
    b = cost_build(p, seam, adapt, rewrite)
    d = cost_defer(p, seam, adapt, rewrite)
    rigid_total += d          # rigid nunca construye costura
    over_total += b           # over-engineered siempre construye
    if b <= d:
        right_total += b
        decision = "CONSTRUIR costura"
        built.append(name)
    else:
        right_total += d
        decision = "diferir (YAGNI)"
        deferred.append(name)
    print(f"{name:<28}{p:>6.2f}{b:>10,.0f}{d:>10,.0f}   {decision}")
print("-" * 74)
print(f"{'rigid (0 costuras, under-engineered)':<44}{rigid_total:>10,.0f}")
print(f"{'over_engineered (costura para TODO)':<44}{over_total:>10,.0f}")
print(f"{'right_sized (costura donde se paga sola)':<44}{right_total:>10,.0f}")
print()
print(f"Construye costura en: {', '.join(built)}.")
print(f"Difiere (YAGNI): {', '.join(deferred)}.")
print("El punto sensato le gana a los dos extremos: la variable que decide es la")
print("PROBABILIDAD del cambio, no el miedo ni la pereza.")

Qué esperar. Al correr el archivo, la salida es exactamente esta:

futuro                           p     build     defer   decision right-sized
--------------------------------------------------------------------------
monolith_to_services          0.90    17,000    81,000   CONSTRUIR costura
second_payments_provider      0.70     7,500    28,000   CONSTRUIR costura
reviews_and_ratings           0.50     9,000    15,000   CONSTRUIR costura
international_currencies      0.25    11,000     6,500   diferir (YAGNI)
plugin_marketplace            0.05    20,750     2,000   diferir (YAGNI)
white_label_multitenant       0.03    25,360     1,050   diferir (YAGNI)
--------------------------------------------------------------------------
rigid (0 costuras, under-engineered)           133,550
over_engineered (costura para TODO)             90,610
right_sized (costura donde se paga sola)        43,050

Construye costura en: monolith_to_services, second_payments_provider, reviews_and_ratings.
Difiere (YAGNI): international_currencies, plugin_marketplace, white_label_multitenant.
El punto sensato le gana a los dos extremos: la variable que decide es la
PROBABILIDAD del cambio, no el miedo ni la pereza.

Lee los tres totales primero, y luego la tabla que los explica, porque aquí se cierra el módulo entero.

Los tres totales: rígido 133550, over-engineered 90610, right-sized 43050. El punto sensato le gana a los dos extremos, y no por poco: cuesta la mitad que el over-engineering y menos de un tercio que el rígido. Esto es lo importante de la lección: no es que el right-sizing sea "un buen compromiso" que sacrifica algo de cada lado; es que domina a los dos. Ni preparar de más ni preparar de menos se acerca a preparar lo justo. La razón es simple una vez que la ves: los dos extremos aplican una sola regla a todos los futuros (rígido: nunca prepares; over: siempre prepara), y una sola regla está mal para algunos futuros por definición. El right-sizing decide futuro por futuro, así que nunca comete el error de aplicar la regla equivocada.

Ahora la tabla, que muestra cómo decide, y es donde vive el criterio del módulo. Mira las dos columnas build y defer para cada futuro, y qué decide el right-sizing:

• monolith_to_services (p=0.90): construir la costura cuesta 17000, reescribir cuesta 81000 esperados. Construir gana por goleada → construir. Es el caso de la lección 6: cambio probable, deja la costura.
• second_payments_provider (p=0.70) y reviews_and_ratings (p=0.50): construir (7500 y 9000) es más barato que reescribir esperado (28000 y 15000) → construir. Cambios probables, costura.
• international_currencies (p=0.25): aquí se cruza la línea. Construir la costura cuesta 11000; el rework esperado es solo 6500. Construir sería más caro que arriesgar la reescritura → diferir. La probabilidad (25%) ya no justifica la costura para este seam/rewrite.
• plugin_marketplace (p=0.05) y white_label_multitenant (p=0.03): construir cuesta 20750 y 25360; el rework esperado es apenas 2000 y 1050 → diferir con claridad. Son los futuros imaginados de la lección 5: probabilidad ínfima, no prepares.

Fíjate en el patrón: el right-sizing construye las tres costuras de arriba (alta probabilidad) y difiere las tres de abajo (baja probabilidad). No hay una regla fija de "sí" o "no"; hay una línea de corte que la probabilidad de cada futuro cruza o no cruza, dado su costo de costura y de reescritura. Eso es exactamente el punto de equilibrio de la lección 3 aplicado futuro por futuro. La frase del código lo resume: la variable que decide es la probabilidad del cambio, no el miedo ni la pereza. El arquitecto que decide por miedo construye todo (over); el que decide por pereza no construye nada (rígido); el que decide por probabilidad construye lo justo (right-sized).

Como barras, la dominancia del punto sensato:

Costo total esperado (USD): los dos extremos vs el punto sensato
 rigid (under-eng)  |####################################  133,550
 over_engineered    |########################               90,610
 right_sized        |###########                            43,050
                     ────────────────────────────────────
 El medio no es un "compromiso": DOMINA a los dos extremos.

Profundización: diseñar para el cambio no es diseñar para todo cambio

Vale la pena detenerse en la frase que ordena la lección, porque es la que separa al arquitecto que entendió el módulo del que lo malentendió: diseñar para el cambio no es diseñar para todo cambio imaginable.

El malentendido es fácil y común. Un arquitecto lee "hay que diseñar para el cambio" (la tesis del módulo) y concluye "entonces mi sistema debe estar preparado para cualquier cambio que se me ocurra". Esa conclusión es el over-engineering directo: como los cambios imaginables son infinitos —Mercado podría volverse una red social, un banco, una plataforma de streaming, lo que sea—, prepararlos todos es imposible, y el intento produce un sistema ahogado en flexibilidad no usada. "Diseñar para el cambio" no puede significar "prepararse para todo", porque "todo" no cabe. Tiene que significar otra cosa, más modesta y más útil: prepararse para el cambio probable, y solo para él. El right-sizing es la disciplina de traducir "diseñar para el cambio" en "diseñar para los pocos cambios que la evidencia dice que probablemente vendrán", no en "diseñar para el catálogo infinito de lo que podría pasar".

De dónde salen las probabilidades —y por qué esto no es adivinación—. Un escéptico dirá: "pero nadie conoce la probabilidad exacta de estos futuros; estás inventando números". Es una objeción justa, y la respuesta es la misma que en la lección 3: el right-sizing no necesita probabilidades exactas, solo necesita ubicarlas respecto a la línea de corte, y para eso hay evidencia real, no adivinación. monolith_to_services tiene probabilidad alta porque el negocio ya está creciendo y las squads ya sienten el dolor del monolito —es una señal, no una corazonada—. second_payments_provider es probable porque finanzas ya está negociando. plugin_marketplace es improbable porque nadie lo ha pedido y no hay estrategia de plataforma. El arquitecto no adivina; lee las señales del negocio —el roadmap, las conversaciones con stakeholders (módulo 5), el dolor que las squads ya reportan (módulo 2)— y ubica cada futuro como claramente probable, claramente improbable, o dudoso. Solo los dudosos requieren juicio fino, y ahí la asimetría de la lección 6 ayuda a resolver. El right-sizing convierte el conocimiento del negocio que el arquitecto ya tiene en decisiones de costura; no inventa probabilidades, las deriva de lo que el negocio está señalando.

La costura no es el servicio: preparar barato, no construir caro. Un punto que las lecciones 5 y 6 tocaron y que aquí conviene consolidar, porque es donde muchos arquitectos se confunden. Cuando el right-sizing dice "construye la costura para monolith_to_services", no dice "construye los microservicios ahora". Dice: deja la costura —la interfaz clara, las tablas separadas, el contrato— que hará barata la futura extracción. La costura es el derecho de vía (barato, hoy), no la avenida pavimentada (cara, cuando haga falta). Confundir las dos cosas reintroduce el over-engineering por la puerta de atrás: "el right-sizing dijo que preparara el monolito-a-servicios, así que construí los servicios" es exactamente pavimentar los doce carriles. La costura correcta para monolith_to_services cuesta 8000 (una decisión de diseño, no un sistema distribuido); construir los servicios costaría cientos de miles y sería prematuro. El right-sizing decide dónde reservar el derecho de vía, no dónde construir la avenida. La avenida se construye cuando el tráfico llega, no antes.

El right-sizing es una foto que se revisa, no una sentencia. Una última consecuencia que conecta con la lección 2 y cierra el círculo del módulo. El portafolio del ejemplo tiene las probabilidades de hoy, y esas probabilidades cambian: un futuro improbable puede volverse probable cuando el negocio se mueve (si Mercado anuncia expansión internacional, international_currencies salta de 0.25 a 0.90 y cruza la línea de corte). Por eso el right-sizing no es una decisión que se toma una vez y se congela —eso sería tratar la arquitectura como final, el error de la lección 2—. Es una revisión periódica: cada cierto tiempo, el arquitecto vuelve al portafolio, actualiza las probabilidades con las señales nuevas del negocio, y reevalúa qué costuras conviene construir ahora que antes se diferían. Diseñar las costuras es en sí mismo un flujo de decisiones, no un artefacto. El arquitecto que right-sizea una vez y nunca revisa se pinta en una esquina distinta: la de un plan de evolución que quedó obsoleto. La postura completa del módulo es circular: la arquitectura es un flujo (L2), así que las costuras se deciden con optionality (L3), evitando los dos abismos (L5, L6), en un right-sizing (L7) que también es un flujo que se revisa. Ninguna decisión es final —ni siquiera la decisión de qué costuras dejar—.

Errores comunes

Confundir "diseñar para el cambio" con "diseñar para todo cambio". Qué pasa: el arquitecto toma la tesis del módulo ("diseña para el cambio") y la lleva a "mi sistema debe estar listo para cualquier cambio imaginable", y cae directo en el over-engineering. Por qué pasa: "diseñar para el cambio" suena a "prepararse", y "prepararse" se desliza fácil a "prepararse para todo". Cómo detectarlo: si el sistema tiene costuras y abstracciones para futuros que nadie ha señalado, o si la justificación de una preparación es "podría pasar cualquier cosa", se confundió cambio con todo cambio. Cómo corregirlo: recordar que diseñar para el cambio es diseñar para el cambio probable —los pocos que la evidencia del negocio señala—, no para el catálogo infinito de lo imaginable. El right-sizing construye tres costuras de seis, no las seis.

Construir la avenida en vez de reservar el derecho de vía. Qué pasa: el right-sizing indica "prepara para este cambio probable" y el arquitecto construye la solución completa por adelantado —los microservicios, el sistema de multi-moneda entero— en vez de solo la costura barata que hará la futura construcción fácil. Por qué pasa: "prepararse" se interpreta como "construir la cosa", no como "dejar el espacio para construirla". Cómo detectarlo: si preparar un cambio probable costó decenas o cientos de miles (no miles), probablemente construiste la avenida, no el derecho de vía. Cómo corregirlo: distinguir la costura (interfaz, contrato, frontera —barata, hoy) de la solución (el servicio, el sistema —cara, cuando el cambio llegue); el right-sizing decide dónde dejar la costura, no dónde construir la solución. En el ejemplo, la costura del monolito cuesta 8000, no los cientos de miles de los servicios.

Right-sizear una vez y congelar el plan. Qué pasa: el arquitecto hace el análisis del portafolio, decide qué costuras construir, y trata esa decisión como definitiva —no vuelve a revisar cuando las probabilidades cambian—. Un futuro que se diferió por improbable se vuelve probable, y nadie reevalúa hasta que el cambio llega sin costura. Por qué pasa: hacer el análisis se siente como cerrar el tema, y revisarlo periódicamente cuesta disciplina. Cómo detectarlo: si el portafolio de futuros se armó hace un año y nadie lo ha vuelto a mirar pese a que el negocio cambió, el plan está congelado. Cómo corregirlo: tratar el right-sizing como un flujo, no como una sentencia —revisarlo periódicamente, actualizar las probabilidades con las señales nuevas del negocio, y reevaluar qué costuras conviene construir ahora—. Es la lección 2 aplicada a la decisión de las costuras: ni siquiera el plan de evolución es final.

Ejercicios

Ejercicio 1 — Mueve una probabilidad. En el ejemplo, international_currencies (p=0.25) se difiere: construir la costura cuesta 11000 y el rework esperado es solo 6500. Ahora marketing anuncia oficialmente la expansión a tres países el año que viene, y la probabilidad sube a 0.90. Sin correr código, recalcula las dos opciones (build y defer) con la nueva probabilidad y di qué decide ahora el right-sizing. ¿Qué enseña esto sobre por qué el right-sizing debe revisarse?

Ver solución

Con international_currencies a p = 0.90 (los otros números iguales: seam = 9000, adapt = 8000, rewrite = 26000):

• build = seam + p × adapt = 9000 + 0.90 × 8000 = 9000 + 7200 = 16200.
• defer = p × rewrite = 0.90 × 26000 = 23400.

Ahora build (16200) es más barato que defer (23400), así que el right-sizing construye la costura —cuando antes, con p = 0.25, la difería—. La decisión se invirtió sin que cambiara ni un número del costo (seam, adapt, rewrite son los mismos); lo único que cambió fue la probabilidad, y eso bastó para cruzar la línea de corte.

Qué enseña: el right-sizing no es una sentencia, es una foto que depende de las probabilidades del momento, y las probabilidades cambian cuando el negocio se mueve. Un futuro que hoy se difiere con razón (improbable) puede volverse probable mañana (un anuncio de marketing, una nueva señal), y entonces la costura que antes no valía la pena ahora sí. Si el arquitecto hubiera right-sizeado una vez y congelado el plan, seguiría difiriendo la costura de multi-moneda incluso después del anuncio de expansión —y llegaría la expansión a encontrarse sin costura, con el checkout hardcodeado a un país, pagando la reescritura de la lección 6—. Por eso el right-sizing debe revisarse periódicamente: es en sí mismo un flujo de decisiones (lección 2), no un artefacto que se congela. Ni siquiera el plan de qué costuras dejar es final.

Ejercicio 2 — Por qué domina, no compromete. El texto insiste en que el right-sizing domina a los dos extremos (43050 contra 90610 y 133550), no que sea "un buen compromiso entre ellos". Explica por qué un compromiso ingenuo —por ejemplo, "construyamos la mitad de las costuras al azar"— no lograría esto, y qué hace exactamente el right-sizing que ningún extremo ni ningún punto medio ciego puede hacer.

Ver solución

Un compromiso ingenuo —"construyamos la mitad de las costuras", elegidas sin criterio— no dominaría a los extremos porque seguiría aplicando una regla ciega a la probabilidad. Si eliges la mitad al azar, podrías construir la costura de plugin_marketplace (p=0.05, donde build=20750 contra defer=2000: un desperdicio enorme) y diferir la de monolith_to_services (p=0.90, donde defer=81000 contra build=17000: una catástrofe). Un punto medio ciego comete los dos errores a la vez —over-engineering en los futuros improbables que preparó, under-engineering en los probables que difirió— y puede salir tan mal o peor que cualquier extremo.

Lo que hace el right-sizing, y que ningún extremo ni punto medio ciego puede hacer, es decidir cada futuro por su propia probabilidad, comparando su costo de construir contra su costo de diferir (el punto de equilibrio de la lección 3, futuro por futuro). Para cada futuro elige la opción más barata de las dos, así que —por construcción— nunca es peor que el mejor de los dos extremos en ese futuro, y casi siempre es estrictamente mejor. Los extremos fallan porque aplican una regla única a todos los futuros: rigid acierta en los improbables (bien difiere) pero se hunde en los probables (mal difiere las costuras baratas); over_engineered acierta en los probables (bien construye) pero desperdicia en los improbables (mal construye costuras carísimas para nada). El right-sizing toma lo bueno de cada extremo futuro por futuro: difiere donde rigid acertaría y construye donde over_engineered acertaría. Por eso no es un compromiso que sacrifica algo de cada lado; es la política óptima que domina a ambos, porque cada decisión individual es la mejor posible. El "medio" del módulo no es promediar los extremos; es elegir bien caso por caso.

Ejercicio 3 — La costura no es la solución. Un arquitecto de Mercado, tras el análisis, anuncia: "el right-sizing dice que preparemos monolith_to_services y second_payments_provider, así que voy a construir los microservicios del catálogo y a integrar los dos proveedores de pago este trimestre". Explica qué malentendió, cuánto le costaría de más su interpretación frente a la correcta, y qué debería construir en realidad.

Ver solución

Malentendió la diferencia entre la costura y la solución —entre reservar el derecho de vía y pavimentar la avenida—. El right-sizing dijo "construye la costura" para esos dos futuros, no "construye la solución completa". La costura de monolith_to_services es una interfaz clara y tablas separadas dentro del monolito (cuesta 8000 en el modelo, una decisión de diseño); construir los microservicios del catálogo es un sistema distribuido entero (redes, despliegues, consistencia), que cuesta órdenes de magnitud más y que el negocio todavía no pidió. Igual con pagos: la costura es una abstracción sobre el proveedor (cuesta 4000); integrar los dos proveedores de verdad es el trabajo caro que se hace cuando el segundo proveedor llega, no antes.

Cuánto le costaría de más: en vez de las dos costuras baratas (8000 + 4000 = 12000), estaría construyendo las dos soluciones completas por adelantado —fácilmente cientos de miles entre los microservicios y la doble integración de pagos—, y encima prematuramente, para cambios que aún no llegaron. O sea, transformó el right-sizing (que le ahorraba dinero) en over-engineering directo (pavimentar los doce carriles): construir la avenida hoy en vez de reservar el derecho de vía. Es exactamente el error de "construir la avenida en vez de reservar el derecho de vía", metiendo el over-engineering por la puerta de atrás con la excusa de que "el análisis lo dijo".

Qué debería construir en realidad: solo las costuras baratas. Para monolith_to_services: que todo acceso al catálogo pase por una interfaz clara (no lecturas directas a sus tablas), que el catálogo tenga sus propias tablas sin joins entrelazados con otros dominios, y un contrato definido —todo dentro del monolito, sin construir ningún servicio—. Para second_payments_provider: una abstracción sobre el proveedor de pagos, de modo que meter el segundo sea un cambio acotado —con un solo proveedor real por ahora—. Eso es reservar el derecho de vía: barato hoy, y convierte la futura construcción (los microservicios, el segundo proveedor) en algo fácil cuando el negocio lo pida. La avenida se pavimenta cuando el tráfico llega; hoy solo se reserva la franja.

Resumen y siguiente paso

En esta lección sintetizaste el módulo: el camino entre los dos abismos es diseñar las costuras en el punto sensato. Grabaste la frase que lo ordena: diseñar para el cambio no es diseñar para TODO cambio imaginable —es construir la costura solo donde el cambio es bastante probable para que se pague sola, y diferir el resto—. Viste, con el urbanista que reserva el derecho de vía donde el crecimiento es probable, que la maestría no es reservar en todas partes (over) ni en ninguna (under), sino elegir dónde. Y lo mediste: el right-sizing cuesta 43050 contra 90610 del over-engineering y 133550 del rígido —no un compromiso, una dominancia—, porque decide futuro por futuro con el punto de equilibrio de la lección 3, construyendo las costuras probables y difiriendo las improbables. Consolidaste tres cosas críticas: las probabilidades se derivan de las señales del negocio (no se adivinan), la costura no es la solución (reserva el derecho de vía, no pavimentes), y el right-sizing es un flujo que se revisa (ni el plan de evolución es final).

Antes de avanzar deberías poder: aplicar la regla del punto de equilibrio futuro por futuro para decidir qué costuras construir; explicar por qué el punto sensato domina a los dos extremos en vez de comprometer; y distinguir la costura (barata, hoy) de la solución (cara, cuando el cambio llegue).

La lección 8 es el proyecto: tomas el rol del arquitecto de Mercado ante el lanzamiento de una capacidad nueva —Mercado Plus, una membresía paga— con un roadmap de cambios anticipados, y produces la evolución planeada de cero, sobre un caso nuevo. Vas a right-sizear el portafolio con tus manos, decidir qué construir hoy, qué sacrificar en un prototipo y qué diferir, y armar el guion de cómo se lo explicas al stakeholder. Todo el módulo, ejecutado por ti.

Recursos

• Neal Ford, Rebecca Parsons y Patrick Kua, Building Evolutionary Architectures (O'Reilly, 2017) — el libro central del módulo, y en especial su idea de guiar la evolución con criterios explícitos (fitness functions) en vez de preparar para todo o para nada. El right-sizing es esa idea aplicada a las costuras. En inglés.
• Eric Evans, Domain-Driven Design (Addison-Wesley, 2003) — los bounded contexts son las costuras naturales de un sistema: las fronteras donde conviene dejar el derecho de vía para futuras extracciones. La fuente de dónde poner las costuras, no solo cuántas. En inglés.
• Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004) — el manual de los seams (costuras): qué son técnicamente y por qué son el punto que hace un sistema modificable. La costura de esta lección viene de aquí. En inglés.
• Martin Fowler, "Design Stamina Hypothesis" (2007) — martinfowler.com/bliki/DesignStaminaHypothesis.html. El punto sensato del diseño entre sub-invertir (under) y sobre-invertir (over) —exactamente lo que el right-sizing calcula—. En inglés. La mecánica de registrar estas decisiones (el ADR) y de clasificar su reversibilidad es la guía hermana architecture-decisions.