Módulo 6: Diseñar para el cambio
Presentación del módulo: diseñar para el cambio
Por qué este módulo existe aquí
Casi todo lo que se dice sobre arquitectura de software esconde un verbo en pasado. "El sistema está diseñado así", "la arquitectura es de microservicios", "decidimos usar una base de datos por servicio". Suena a fotografía: un estado fijo que alguien capturó y que ahí se queda. Y esa gramática es una trampa, porque un sistema vivo no es una fotografía —es una película—. Cambia todos los días: entran features, crecen los volúmenes, el negocio pivota, aparecen requisitos que nadie imaginó el día que se dibujó el primer diagrama. La pregunta que casi nadie hace, y que este módulo pone en el centro, no es "¿cuál es la arquitectura correcta?" sino "¿está esta arquitectura postulada para cambiar cuando el negocio lo pida, o va a pelear contra cada cambio hasta que reescribirla sea la única salida?".
Esta guía completa enseña el oficio humano y organizacional de ser arquitecto. En el módulo 1 desmontaste el mito del rol —el arquitecto no produce diagramas, produce condiciones—. En el 2 viste cómo la organización moldea el sistema (Conway). En el 3 aprendiste a comunicar con el C4 y el ADR. En el 4, a liderar sin autoridad. En el 5, a traducir metas de negocio en atributos de calidad. Todos esos módulos descansaban sobre un supuesto que nunca dijeron en voz alta: que una vez que decides bien, la cosa se queda quieta. Este módulo saca ese supuesto a la luz y lo desmonta. Ninguna arquitectura es final. El trabajo del arquitecto no termina cuando el diseño se aprueba; ahí apenas empieza la parte larga: acompañar la evolución del sistema durante años de cambios que no estaban en el plano.
Y aquí hay que ser preciso con la frontera del ecosistema, porque es delicada. La guía hermana architecture-decisions-and-tradeoffs enseña la mecánica de decidir bajo cambio: cómo clasificar una decisión como puerta de una o de dos vías, cómo calcular el último momento responsable, cómo medir y pagar deuda técnica. Eso es técnica, y no la re-enseñamos aquí. Este módulo enseña la postura mental del arquitecto que encarna esa técnica: la disposición interna de quien planea para el cambio y no para la permanencia, quien mantiene opciones abiertas por oficio, quien construye a sabiendas cosas que va a tirar, y quien camina entre el over-engineering y el under-engineering sin caer en ninguno. La técnica es de la otra guía; la identidad profesional que la usa es de esta. Cuando en este módulo hablemos de "dejar una costura", no vamos a re-enseñar cómo se clasifica una puerta de una vía —eso es la otra guía—; vamos a enseñar por qué un arquitecto que diseña para el cambio deja esa costura por postura, no por accidente.
El caso, mirado en el tiempo: Mercado y su monolito que será servicios
Mercado es el marketplace que nos acompaña toda la guía, y aquí lo miramos con una lente distinta: el tiempo. Recuerda su organización —cinco squads: catalog, orders, payments, shipping, platform—. Y recuerda su sistema, que en el módulo 2 diagnosticamos como un monolito: un solo despliegue grande, con una base de datos compartida, nacido cuando Mercado era un equipo chico y un producto simple.
El arquitecto de Mercado sabe algo que no aparece en ningún diagrama actual: que el monolito de hoy será servicios mañana. No lo sabe porque el monolito esté mal —para el Mercado de hoy, con su tamaño y su tráfico, el monolito es probablemente la decisión correcta; partirlo ahora sería sobre-ingeniería—. Lo sabe porque el negocio va a crecer, va a presionar las costuras, y llegará el momento en que un pedazo del monolito —el catálogo, los pagos, el envío— necesitará vivir aparte para escalar, para desplegarse solo, para que un equipo lo posea entero. Ese momento va a llegar. La pregunta del arquitecto no es si llegará, sino: cuando llegue, ¿el monolito estará postulado para dejar salir ese servicio sin dolor, o habrá que reescribir medio sistema?
Ahí está el oficio de este módulo, y es un equilibrio fino:
- Si el arquitecto, temeroso del futuro, reescribe el monolito en microservicios hoy —cuando el negocio aún no lo pide—, comete over-engineering: paga la complejidad de un sistema distribuido (redes, latencia, consistencia eventual, cinco despliegues) para un problema que todavía no tiene. Construyó flexibilidad para un futuro que quizá tarda años, o no llega.
- Si el arquitecto, por simplicidad mal entendida, suelda el monolito en una bola sin fronteras internas —todo llama a todo, la base de datos es un enredo compartido, no hay una sola costura—, comete under-engineering: cuando el negocio pida sacar el catálogo aparte, no habrá por dónde cortar, y la extracción costará una fortuna en reescritura. Se pintó en una esquina.
- El arquitecto que diseña para el cambio hace lo tercero: mantiene el monolito —simple, un despliegue— pero deja las costuras puestas. Dentro del monolito, el catálogo habla con los pedidos por una interfaz clara, no metiéndole mano a sus tablas; los módulos tienen fronteras internas aunque compartan proceso; hay un contrato donde mañana habrá una red. El día que el negocio pida el servicio de catálogo aparte, la costura ya está: se corta por la línea de puntos, no se reescribe.
Ese tercer arquitecto es el protagonista del módulo. No adivina el futuro; postula el sistema para recibirlo. Y lo hace midiendo, no por corazonada.
Conexión con el módulo. Esta es la lección-mapa. No entra a fondo en ninguna de las siete piezas; instala la tesis (ninguna arquitectura es final; es un flujo de decisiones, y el oficio es diseñar las costuras entre dos abismos), el vocabulario (optionality, sacrificial architecture, YAGNI, over-engineering, under-engineering, seam/costura, right-sizing) y el mapa de cómo cada lección construye la postura. La lección 2 instala que la arquitectura es un flujo, no un artefacto congelado. La 3 enseña la optionality: mantener puertas abiertas bajo incertidumbre. La 4, la arquitectura sacrificial: construir para tirar. La 5 marca el primer abismo, el over-engineering (YAGNI). La 6, el segundo, el under-engineering (pintarse en una esquina). La 7 sintetiza: diseñar las costuras en el punto sensato. Y la 8 te pone a diseñar la evolución de Mercado ante un cambio real, ejecutado. Cuidado con la frontera: la reversibilidad y el último momento responsable como técnica son la guía hermana architecture-decisions (su módulo 7); aquí trabajamos la postura de quien la encarna.
Y la promesa de siempre: aunque el tema es una postura mental, lo cuantificable se ejecuta, no se afirma. Cada simulación corre con Python 3.14 y solo la biblioteca estándar, con datos fijos, así que la salida de cada bloque "Qué esperar" es la salida literal de correr el código. Puedes copiarlo y reproducirlo idéntico.
Una analogía: el urbanista que reserva el terreno para la avenida que aún no existe
Piensa en cómo se planea una ciudad, y en dos urbanistas frente al mismo terreno vacío en las afueras.
El primer urbanista diseña para el presente y solo para el presente. Hoy hay un pueblo pequeño, así que traza calles angostas, junta las casas hasta el borde de cada lote, y usa cada metro cuadrado disponible —"¿para qué dejar espacio vacío si no hay tráfico?"—. Es eficiente, se ve lleno y aprovechado. Diez años después el pueblo es una ciudad, el tráfico colapsa, y hace falta una avenida grande que cruce la zona. Pero no hay por dónde: las casas están pegadas unas a otras, cada metro está construido. Abrir la avenida ahora significa expropiar y demoler cientos de casas, a un costo político y económico brutal. El urbanista optimizó para el presente y pintó la ciudad en una esquina.
El segundo urbanista comete el error contrario. Aterrado por el futuro, pavimenta desde el día uno una avenida de doce carriles, con distribuidores viales, puentes y un aeropuerto —para un pueblo de tres mil habitantes—. Todo eso cuesta una fortuna, la mitad se agrieta sin usarse porque no hay tráfico que lo justifique, y el mantenimiento de una infraestructura sobredimensionada se come el presupuesto del pueblo por décadas. Construyó para un futuro imaginado que quizá nunca llega —o llega tan tarde que la infraestructura ya está obsoleta—. Over-engineering urbano.
El tercer urbanista —el bueno— hace algo mucho más sutil. No construye la avenida. Pero reserva el derecho de vía: deja una franja de terreno sin edificar por donde, el día que el tráfico lo pida, se podrá abrir la avenida sin demoler nada. No pavimenta doce carriles hoy; deja el espacio para pavimentarlos mañana, barato. La franja reservada casi no cuesta —es terreno que no se vende para casas—, pero cambia el futuro por completo: cuando la ciudad crezca, la avenida se abre por la franja que siempre estuvo ahí, sin expropiaciones ni demoliciones. El urbanista no adivinó cuándo vendría el tráfico ni cuántos carriles harían falta; postuló la ciudad para recibir la avenida cuando fuera necesaria.
Esa franja reservada es la costura (el seam) de este módulo. El arquitecto que diseña para el cambio no construye el futuro por adelantado (over-engineering, el segundo urbanista) ni se pinta en una esquina construyendo todo hasta el borde (under-engineering, el primero). Deja las costuras —el derecho de vía— donde el cambio probable va a pasar: la interfaz clara entre catálogo y pedidos, el contrato donde mañana habrá una red, la abstracción que deja intercambiar el proveedor de pagos. Barato hoy, decisivo mañana. Y la maestría, igual que en la ciudad, está en saber dónde reservar terreno (para la avenida que probablemente vendrá) y dónde no (para el aeropuerto que casi seguro no). Este módulo entrena esa maestría, y la pone en números.
Ejemplo trabajado: la vida media del diseño del día uno
Empecemos por la evidencia más dura de la tesis: ninguna arquitectura es final. No es una opinión filosófica; es medible. Un diseño no se vuelve obsoleto de golpe el día que "falla"; se erosiona despacio, suposición por suposición, a medida que el negocio invalida las premisas sobre las que se dibujó. Vamos a medir cuánto del diseño del día uno de Mercado sigue en pie con el paso de los años.
Tomamos ocho suposiciones de la arquitectura inicial de Mercado —cosas que el diseño del día uno dio por ciertas—. Cada una tiene una probabilidad anual de quedar invalidada por un cambio de negocio: que Mercado abra un segundo país invalida single_region y english_only; que crezca el volumen de pagos invalida one_payments_provider; que el checkout no pueda caerse invalida synchronous_orders_to_shipping; y así. No es que vayan a morir seguro; es que cada año corren cierto riesgo de que el negocio las tumbe. Medimos cuántas suposiciones del diseño original se espera que sigan vivas año tras año:
# Ninguna arquitectura es final. Las suposiciones del diseno del dia 1 no mueren
# de golpe: el negocio las va invalidando una por una con el tiempo. Cada suposicion
# de la arquitectura inicial de Mercado tiene una probabilidad ANUAL de quedar
# invalidada por un cambio de negocio. Medimos que fraccion del diseno original
# sigue en pie ano tras ano.
ASSUMPTIONS = [
# (suposicion_del_dia_1, prob_invalidada_por_ano)
("single_shared_database", 0.25),
("one_payments_provider", 0.30),
("synchronous_orders_to_shipping", 0.20),
("monolith_deploy", 0.35),
("single_region", 0.15),
("no_external_api", 0.30),
("english_only", 0.20),
("session_in_memory", 0.25),
]
total = len(ASSUMPTIONS)
print(f"{'ano':>4}{'suposiciones vivas (esperado)':>32}{'% del diseno dia 1':>22}")
print("-" * 58)
for year in range(0, 6):
alive = sum((1 - p) ** year for _, p in ASSUMPTIONS)
print(f"{year:>4}{alive:>32.2f}{alive / total * 100:>21.1f}%")
print("-" * 58)
survive5 = sum((1 - p) ** 5 for _, p in ASSUMPTIONS)
print(f"De {total} suposiciones del dia 1, al ano 5 sobreviven ~{survive5:.1f}")
print(f"(el {survive5 / total * 100:.0f}% del diseno original). Cerca del ano 2-3 ya se")
print("invalido la MITAD. El 'diseno definitivo' no existe: es un flujo de decisiones.")Qué esperar. Al correr el archivo, la salida es exactamente esta:
ano suposiciones vivas (esperado) % del diseno dia 1
----------------------------------------------------------
0 8.00 100.0%
1 6.00 75.0%
2 4.53 56.6%
3 3.44 43.0%
4 2.63 32.9%
5 2.03 25.3%
----------------------------------------------------------
De 8 suposiciones del dia 1, al ano 5 sobreviven ~2.0
(el 25% del diseno original). Cerca del ano 2-3 ya se
invalido la MITAD. El 'diseno definitivo' no existe: es un flujo de decisiones.
Lee la columna del porcentaje despacio, porque es el argumento entero del módulo en una tabla.
El día cero, el 100% del diseño está vigente —claro, se acaba de dibujar—. Al año 1, ya se espera que el 25% de las suposiciones haya caído: solo sobrevive el 75%. Al año 2 estás en 56.6%, y entre el año 2 y el 3 el diseño cruza la mitad: más de la mitad de las premisas con las que se dibujó la arquitectura original ya no aplican. Al año 5, apenas el 25% del diseño del día uno sigue en pie. Tres cuartas partes de las suposiciones sobre las que se construyó Mercado quedaron invalidadas por el negocio en cinco años —no por mal diseño, sino porque el mundo se movió—.
Esta es la vida media de una arquitectura, y tiene una consecuencia demoledora para la idea del "diseño definitivo". Si en cinco años el 75% de tus premisas van a cambiar, entonces perseguir el diagrama perfecto que aguante para siempre es perseguir un fantasma: el 75% de ese diagrama perfecto va a estar equivocado en cinco años, no importa qué tan bien lo dibujes hoy, porque no puedes dibujar contra un mundo que aún no ocurrió. El diseño perfecto y permanente no existe. Lo que existe es un flujo de decisiones: una arquitectura que recibe una decisión nueva cada vez que una suposición cae, y que está —o no está— postulada para recibirla barato.
Fíjate en el giro de mentalidad que esto obliga. El arquitecto de la fotografía se pregunta: "¿cuál es el diseño correcto?" —y trata de acertarlo de una—. El arquitecto de la película se pregunta otra cosa: "cuando esta suposición caiga —y va a caer—, ¿mi arquitectura va a poder absorber el cambio, o va a pelear contra él?". La primera pregunta persigue una permanencia imposible; la segunda diseña para lo único seguro, que es el cambio. Todo el módulo desarrolla la segunda pregunta: cómo mantener opciones abiertas (lección 3), cuándo construir para tirar (lección 4), y —el corazón— dónde poner las costuras sin caer en el over-engineering (lección 5) ni en el under-engineering (lección 6), en el punto sensato que la lección 7 mide.
Un matiz honesto antes de seguir: que el 75% de las suposiciones cambien en cinco años no significa que haya que rediseñarlo todo cada año, ni que planear no sirva. Significa lo contrario: como sabes que el diseño va a erosionarse, planeas para que erosionarse sea barato —dejando costuras— en vez de planear un diseño que finge que no va a erosionarse. La lección no es "no diseñes"; es "diseña para el flujo, no para la foto".
Las seis piezas de la postura
Ese ejemplo tocó, sin desarrollarla, la tesis del módulo. Cada lección instala una pieza de la postura del arquitecto que diseña para el cambio. Vale la pena verlas juntas, porque son la columna vertebral de las siete lecciones que siguen.
1. La arquitectura es un flujo, no una foto (lección 2). La primera pieza: dejar de pensar la arquitectura como un artefacto que se congela y empezar a pensarla como un flujo de decisiones que corre toda la vida del sistema. Se mide el costo acumulado de la postura "congelada" contra la "fluida": no quiebra un cambio, quiebra la acumulación.
2. Mantener las puertas abiertas —optionality (lección 3). Bajo incertidumbre, una opción abierta tiene valor aunque nunca la ejerzas, como un seguro. Pero cuesta una prima. La lección mide cuándo la prima vale la pena (cuando el cambio es bastante probable) y cuándo se desperdicia (cuando no) —el punto de equilibrio—.
3. Construir para tirar —sacrificial architecture (lección 4). A veces la mejor manera de reducir la incertidumbre es construir a sabiendas algo desechable: un prototipo que valida y se reemplaza. No es desperdicio; es el andamio que se paga para levantar bien el edificio. La lección mide cuándo el prototipo sale más barato que construir "de una".
4. El primer abismo: el over-engineering —YAGNI (lección 5). Construir flexibilidad "por si acaso" para futuros imaginados que casi nunca llegan. La lección mide el desperdicio: pagar por la flexibilidad de todos los futuros contra pagar el rework solo de los que arriban —un orden de magnitud de diferencia—.
5. El segundo abismo: el under-engineering (lección 6). El error opuesto: negarse a dejar una sola costura y pintarse en una esquina, de modo que el cambio probable cuesta una reescritura. La lección mide su costo cuando el cambio llega.
6. La síntesis: diseñar las costuras (lección 7). El punto sensato entre los dos abismos: costura donde el cambio es probable, diferir donde no. Diseñar para el cambio no es diseñar para todo cambio imaginable. La lección mide el right-sizing contra los dos extremos, y gana.
Guarda este mapa; es la ruta del módulo:
Pieza de la postura Leccion La idea en una frase
────────────────────────────────── ──────── ─────────────────────────────────────
La arquitectura es un flujo L2 pensar en pelicula, no en foto
Optionality (puertas abiertas) L3 la opcion vale una prima, bajo duda
Sacrificial architecture L4 el andamio se paga para construir bien
El abismo del over-engineering L5 YAGNI: no lo construyas hasta necesitarlo
El abismo del under-engineering L6 no te pintes en una esquina
Disenar las costuras (el medio) L7 costura donde el cambio es PROBABLE
────────────────────────────────── ──────── ─────────────────────────────────────
Disena la evolucion de Mercado L8 el mini-proyecto, ejecutado
El mapa: dónde está este módulo en la guía y en el ecosistema
Este módulo es el penúltimo de la guía, y cierra el arco del oficio con la dimensión del tiempo. Así se conecta con el resto:
flowchart TD
M1["M1 · Que hace de verdad un arquitecto"]
M2["M2 · La ley de Conway"]
M3["M3 · Comunicar la arquitectura (C4)"]
M4["M4 · Liderazgo tecnico sin autoridad"]
M5["M5 · Stakeholders y atributos de calidad"]
M6["M6 · Disenar para el cambio<br/>(la postura ante la evolucion)"]
M7["M7 · Documentacion que sobrevive"]
M8["M8 · Proyecto: ser el arquitecto de<br/>Mercado ante un cambio"]
M1 --> M2 --> M3 --> M4 --> M5 --> M6 --> M7 --> M8
Léelo así: en los módulos 1 a 5 instalaste el rol, la dinámica org↔sistema, la comunicación, el liderazgo y la traducción de metas a atributos. Aquí, en M6, agregas la postura ante el tiempo: el sistema va a cambiar, y el arquitecto lo postula para recibir el cambio. En M7 aprenderás a documentar de forma que el conocimiento sobreviva a ese cambio y al recambio de personas. Y en M8 harás todo el recorrido como arquitecto de Mercado ante un cambio real.
Y la frontera con la guía hermana, que hay que respetar con cuidado porque es la más cercana de todo el ecosistema: architecture-decisions-and-tradeoffs enseña la mecánica de decidir bajo cambio —clasificar una decisión por su reversibilidad (puertas de una o de dos vías), calcular el último momento responsable, medir y pagar deuda técnica—. Eso es técnica, y su módulo 7 la cubre a fondo. Este módulo enseña la postura mental de quien encarna esa técnica: la disposición de planear para el cambio, mantener opciones, construir para tirar y evitar los dos abismos. Cuando en la lección 3 hablemos de "mantener una puerta abierta", no vamos a re-enseñar cómo se clasifica formalmente una puerta de una o de dos vías (eso es la otra guía); vamos a enseñar por qué mantener puertas abiertas es parte de lo que significa ser arquitecto. La distinción es la de siempre en esta guía: la herramienta contra el oficio de quien la empuña.
Errores comunes
Estos tres errores son las tres formas de fallar frente al cambio que el módulo entero combate. Aparecen aquí en su forma de resumen; cada lección abre uno a fondo.
Tratar la arquitectura como final (el diseño congelado). Qué pasa: el arquitecto invierte todo su esfuerzo en el diseño inicial, lo aprueba, y luego trata cada cambio del negocio como una molestia que "rompe" la arquitectura, en vez de como el estado normal de un sistema vivo. El sistema pelea contra cada feature nueva. Por qué pasa: la cultura y el vocabulario empujan a pensar en fotos ("el sistema es así"), no en películas; y un diseño terminado se siente como un logro que hay que defender, no como una hipótesis que hay que revisar. Cómo detectarlo: si cada cambio de negocio se vive como una emergencia arquitectónica, si escuchas "eso rompe la arquitectura" ante features razonables, o si el sistema va acumulando parches porque nadie está dispuesto a moverlo, la arquitectura se está tratando como congelada. Cómo corregirlo: adoptar la postura del flujo —el diseño es una hipótesis que el negocio va a corregir— y postular el sistema para recibir cambio con costuras, en vez de defender un diseño que la realidad ya invalidó. La lección 2 lo mide: el costo acumulado de la postura congelada es 2.7 veces el de la fluida.
Over-engineering: construir para todo futuro imaginable (romper YAGNI). Qué pasa: el arquitecto, para "estar preparado", construye flexibilidad, abstracciones y capas de configuración para futuros que imagina pero que casi nunca llegan —el sistema de plugins genérico, el motor de reglas configurable, los microservicios "porque vamos a escalar"—. El resultado es un sistema complejo, caro de mantener, cuya flexibilidad nadie usa. Por qué pasa: viene de un buen lugar mal calibrado —el miedo a pintarse en una esquina— pero confunde "diseñar para el cambio probable" con "diseñar para todo cambio imaginable". Cómo detectarlo: si hay abstracciones con un solo caso de uso, configuración que nadie configura, o infraestructura distribuida para un tráfico que no existe, es over-engineering. Cómo corregirlo: aplicar YAGNI —no construir la flexibilidad hasta que el cambio sea bastante probable para pagarla— y medir la probabilidad, no el miedo. La lección 5 lo cuantifica: pre-construir todos los futuros imaginados cuesta 25 veces más que pagar el rework de los que de verdad llegan.
Under-engineering: pintarse en una esquina (el opuesto). Qué pasa: el arquitecto, por simplicidad mal entendida o por prisa, no deja ninguna costura —todo llama a todo, sin fronteras, sin abstracciones— y cuando el cambio probable llega, no hay por dónde entrar: hay que reescribir. Por qué pasa: a veces por pereza, a veces por una lectura ingenua de YAGNI ("no prepares nada"), a veces por presión de entregar rápido sin pensar en el mañana. Cómo detectarlo: si un cambio que el negocio claramente iba a pedir (un segundo proveedor de pagos, sacar un módulo a un servicio) implica una reescritura desproporcionada porque "todo está pegado", te pintaste en una esquina. Cómo corregirlo: dejar la costura barata para los cambios probables —no para todos, pero sí para esos—, que es exactamente el punto sensato. La lección 6 lo mide: reescribir sin costura cuesta 4.3 veces más que haber dejado la costura barata. Y la lección 7 muestra que el arte está en distinguir el cambio probable (deja costura) del imaginado (no la dejes).
Ejercicios
Ejercicio 1 — ¿Foto o película? Un arquitecto nuevo llega a Mercado y, en una reunión, dice: "voy a dedicar el próximo mes a diseñar la arquitectura definitiva del sistema, para que no tengamos que volver a tocarla en años". Usando el ejemplo de la vida media del diseño, explica por qué esa frase revela una postura equivocada, y cómo reformularía la meta un arquitecto que diseña para el cambio.
Ver solución
La frase "la arquitectura definitiva, para no volver a tocarla en años" revela la postura de la fotografía: cree que existe un diseño que se dibuja una vez y se congela. El ejemplo de la vida media muestra por qué eso es un fantasma: en Mercado, al año 5 solo el 25% de las suposiciones del diseño del día uno sigue vigente —tres cuartas partes cambian en cinco años, no por mal diseño sino porque el negocio se mueve—. Un mes de trabajo para producir un diseño "definitivo" es un mes gastado contra un mundo que aún no ocurrió: el 75% de ese diseño va a estar equivocado en cinco años pase lo que pase, porque no se puede diseñar contra el futuro que no llegó.
Un arquitecto que diseña para el cambio reformularía la meta así: en vez de "diseñar la arquitectura definitiva", "diseñar una arquitectura que reciba los cambios previsibles baratos" —dejando costuras donde el negocio probablemente va a presionar—. La pregunta no es "¿cuál es el diseño correcto para siempre?" sino "cuando estas suposiciones caigan —y van a caer—, ¿mi sistema podrá absorber el cambio o va a pelear contra él?". Es la diferencia entre planear una foto y planear una película. El mismo mes de trabajo, bien enfocado, no produce un diseño definitivo (imposible); produce un sistema postulado para evolucionar (que es lo que sí se puede hacer).
Ejercicio 2 — Los dos abismos, en Mercado. Para cada una de estas dos decisiones del arquitecto de Mercado, di cuál de los dos abismos (over-engineering o under-engineering) representa, y por qué: (a) "vamos a reescribir el monolito en 30 microservicios ahora, con un service mesh y un event bus, porque algún día vamos a escalar"; (b) "vamos a poner toda la lógica de pagos directamente en el checkout, leyendo y escribiendo las tablas de payments desde orders, así es más rápido de hacer".
Ver solución
(a) es over-engineering (romper YAGNI). Reescribir el monolito en 30 microservicios con service mesh y event bus ahora —cuando el negocio "algún día va a escalar" pero todavía no lo pide— construye una enorme flexibilidad y complejidad (redes, latencia, consistencia eventual, 30 despliegues, la infraestructura de un sistema distribuido) para un futuro imaginado que quizá tarda años o llega distinto de lo esperado. Paga hoy el costo de un problema que aún no tiene. El síntoma clásico: la justificación es "por si acaso" / "algún día", no un cambio probable y cercano. La corrección es mantener el monolito y dejar las costuras para extraer servicios cuando el negocio lo pida, no construir los 30 servicios por adelantado.
(b) es under-engineering (pintarse en una esquina). Que orders lea y escriba directamente las tablas de payments borra la costura entre los dos módulos: los pega en una bola sin frontera. Es más rápido de hacer hoy, sí, pero cuando el negocio pida algo probable —un segundo proveedor de pagos, sacar payments a un servicio para que un equipo lo posea, cumplir una regulación que aísle los datos de pago—, no habrá por dónde cortar: la lógica de pagos está enredada dentro del checkout. La extracción costará una reescritura. El síntoma clásico: se optimizó la velocidad de hoy borrando una frontera que el negocio probablemente iba a necesitar. La corrección es dejar la costura barata —orders habla con payments por una interfaz clara, no metiéndole mano a sus tablas—, que casi no cuesta hoy y ahorra la reescritura mañana.
El módulo entero vive entre estos dos abismos: (a) construye demasiado para lo improbable; (b) construye de menos para lo probable. El punto sensato (lección 7) es dejar costura donde el cambio es probable —la frontera payments/orders de (b)— y no construir donde es improbable —los 30 microservicios de (a)—.
Ejercicio 3 — El derecho de vía. Traduce la analogía del urbanista a Mercado. El arquitecto sabe que, si el negocio crece, el módulo de catálogo probablemente tendrá que salir del monolito a su propio servicio (para escalar y para que la squad catalog lo posea entero). ¿Qué sería el "derecho de vía" —la costura barata que se deja hoy— para esa extracción futura, y por qué dejarla ahora es más barato que abrir la avenida después?
Ver solución
El "derecho de vía" para la futura extracción del catálogo es una costura arquitectónica que se deja hoy, barata, dentro del monolito, sin construir todavía el servicio aparte. En concreto, sería algo como: (1) que todo el acceso al catálogo pase por una interfaz clara (un módulo o una capa) en vez de que otros módulos lean directamente las tablas de catálogo —así la frontera existe aunque hoy sea una llamada en memoria y mañana sea una llamada de red—; (2) que los datos del catálogo tengan sus propias tablas, no entrelazadas con las de otros módulos en joins que sería imposible partir; (3) un contrato definido de qué pide y qué devuelve el catálogo, aunque hoy viva en el mismo proceso. Nada de eso es construir el microservicio: es dejar la franja de terreno reservada por donde, el día que haga falta, se abrirá la avenida.
Por qué dejarla hoy es más barato que abrir la avenida después: si no se deja la costura y otros módulos leen directamente las tablas del catálogo y hacen joins con ellas por todos lados (under-engineering), extraer el catálogo mañana significa desenredar todas esas dependencias —encontrar cada lugar que toca las tablas del catálogo, reescribirlo para que use una interfaz, migrar los datos, romper los joins—: una reescritura grande y arriesgada, como demoler las casas que se construyeron sobre la franja. En cambio, dejar la interfaz y las tablas separadas hoy cuesta casi nada (es una decisión de diseño, no código extra significativo) y convierte la extracción futura en "cambiar la llamada en memoria por una llamada de red" —cortar por la línea de puntos—. Es exactamente el derecho de vía del urbanista: la franja reservada casi no cuesta, pero es la diferencia entre abrir la avenida sin demoler nada y expropiar media ciudad.
Y el matiz que anticipa la lección 7: esto se justifica porque la extracción del catálogo es un cambio probable (el negocio va a crecer, la squad lo va a querer poseer). Para un cambio improbable —digamos, "convertir Mercado en una plataforma white-label multi-tenant"— dejar la costura no se justificaría: sería reservar terreno para un aeropuerto que casi seguro no vendrá (over-engineering). El derecho de vía se reserva para la avenida probable, no para toda infraestructura imaginable.
Resumen y siguiente paso
En esta lección instalaste la tesis que sostiene todo el módulo: ninguna arquitectura es final. No es una foto que se congela el día uno; es una película, un flujo de decisiones que corre toda la vida del sistema. Lo mediste: en Mercado, el 75% de las suposiciones del diseño del día uno se invalidan en cinco años —no por mal diseño, sino porque el negocio se mueve—, así que perseguir el diagrama perfecto y permanente es perseguir un fantasma. Viste, con los tres urbanistas, que el oficio no es ni construir el futuro por adelantado (over-engineering, el aeropuerto para tres mil habitantes) ni pintarse en una esquina (under-engineering, las casas pegadas sin lugar para la avenida), sino reservar el derecho de vía: dejar las costuras baratas donde el cambio probable va a pasar. Y aterrizaste todo en Mercado: el arquitecto que sabe que el monolito de hoy será servicios mañana, y lo postula para dejar salir ese servicio sin dolor.
Antes de avanzar deberías poder: explicar por qué "el diseño definitivo" es un fantasma usando la idea de la vida media; distinguir los dos abismos (over-engineering y under-engineering) con un ejemplo de Mercado; y traducir "dejar una costura" a la analogía del derecho de vía —barato hoy, decisivo mañana—.
La lección 2 toma la primera pieza de la postura y la desarrolla a fondo: la arquitectura como un flujo de decisiones, no como un artefacto congelado. Vas a ver por qué lo que quiebra un sistema no es un cambio grande, sino la acumulación de cambios contra una estructura que no fue diseñada para moverse —y a ejecutar el costo acumulado de la postura congelada contra la fluida a lo largo de la vida de Mercado—. Con números, para que "la arquitectura es un flujo" deje de ser un eslogan y sea una medición.
Recursos
- Martin Fowler, "Sacrificial Architecture" (2014) — martinfowler.com/bliki/SacrificialArchitecture.html. El texto que da nombre a una de las piezas del módulo (lección 4): construir a sabiendas algo que se reemplazará. Fowler parte de que ninguna arquitectura es final, la tesis de esta lección. Corto y esencial. En inglés.
- Martin Fowler, "Yagni" (2015) — martinfowler.com/bliki/Yagni.html. La fuente de la línea del YAGNI que trabaja la lección 5: por qué construir para futuros imaginados casi siempre sale caro. En inglés.
- Neal Ford, Rebecca Parsons y Patrick Kua, Building Evolutionary Architectures (O'Reilly, 2017) — el libro central del módulo. Su premisa es exactamente la de esta guía: la arquitectura debe diseñarse para evolucionar, porque el cambio es la constante. En inglés.
- Mark Richards y Neal Ford, Fundamentals of Software Architecture, 2ª ed. (O'Reilly, 2020), cap. 3–4 ("Modularity / Architecture Characteristics") — el marco de por qué las fronteras internas (las costuras) importan y cómo se piensan. En inglés.
- Andrew Hunt y David Thomas, The Pragmatic Programmer, 20th Anniversary Edition (Addison-Wesley, 2019), temas "Reversibility" y "Good-Enough Software" — la raíz de la postura: no hay decisiones finales, y el software que evoluciona bien es el que no se casó con supuestos irreversibles. En inglés.