Mapa del curso: 31 conceptos en ocho grupos

Un mapa del metro: primero ves todas las líneas juntas, luego viajas estación por estación.

La arquitectura no es un conjunto de tecnologías — es un conjunto de preguntas que se hacen antes de escribir código. Cada pregunta tiene su propio nombre en la industria: Trade-offs, Coupling, Idempotency, ADR. El curso las reúne en ocho grupos — los capítulos 1–8 los siguen.

Cómo leer este curso

Un pasaporte: todos tienen los mismos campos, así que es fácil compararlos.

Cada concepto recibe el mismo trato: su nombre canónico (recuérdalo — es el término que vas a buscar y por el que te van a preguntar en entrevistas), una imagen de la vida real, un diagrama y una ficha con campos: qué es, por qué, ejemplo, trampa (dónde suele equivocarse la gente) y conceptos relacionados. Cada capítulo termina con su pregunta clave; el curso termina con listas de verificación y una hoja de referencia.

Problem Framing — cuestiona la tarea, no solo la solución

Un paciente entra al consultorio pidiendo una receta. El buen médico primero pregunta qué le duele — y puede descubrir que el remedio pedido habría sido un error.

Cuando alguien dice «haz X», el ingeniero pregunta «cómo hago X». El arquitecto pregunta «para qué hace falta X, y si otra cosa resolvería el problema real». Eso es problem framing. Con frecuencia la tarea está mal planteada — y la solución que alguien encargó se vuelve, un año después, el problema.

Long-term Thinking — un horizonte de años, responsabilidad por las consecuencias

Un ingeniero construye una casa para la familia que se muda el sábado. Un arquitecto pregunta: «¿Y cuando tengan el tercer hijo? ¿Y cuando la madre se mude con ellos? ¿Y si quieren alquilar la planta baja?»

El ingeniero resuelve el problema tal como está planteado. El arquitecto resuelve el problema tal como se verá dentro de tres años. Eso significa diseñar capacidades que aún no hacen falta, y dejar fuera, a conciencia, las que suenan elegantes pero nunca se van a usar.

Si el carpintero clava un clavo torcido, lo arregla en un día. Si el arquitecto pone un muro de carga en el lugar equivocado, la casa ya no se rehace — hay que vivir en ella.

Por eso el arquitecto responde por las consecuencias, no por el código. El error del ingeniero se corrige en una semana. El error del arquitecto la empresa lo paga durante años — en deuda técnica, en equipos perdidos, en oportunidades que no se aprovecharon. El arquitecto tiene que pensar antes de que se escriba la primera línea, y tener el coraje de frenar el desarrollo si la arquitectura no resiste los requisitos reales.

Trade-offs — toda decisión gana algo y pierde algo

La bicicleta es más rápida que caminar, pero te mojas bajo la lluvia. El auto no te moja, pero queda atrapado en el tráfico. El metro no se atasca, pero no te deja en la puerta.

Cuando el ingeniero elige una tecnología, suele buscar «la mejor». Es una ilusión. El arquitecto sabe: cualquier elección es un compromiso sobre varios ejes — velocidad de desarrollo contra mantenibilidad, simplicidad contra flexibilidad, costo ahora contra costo dentro de tres años. Nombrar los ejes y elegir conscientemente es el trabajo arquitectónico.

Simplicity (KISS) — la solución simple casi siempre es la más acertada

Una navaja suiza lo hace todo, y todo mal. Un buen cuchillo corta mejor que todos sus hermanos dentro de la navaja suiza.

El ingeniero teme perder un requisito y llena el sistema con todo lo que alguna vez podría hacer falta. El arquitecto sabe: cada capacidad que nadie usa es un impuesto permanente sobre el desarrollo. La complejidad se introduce a conciencia, cuando está justificada; por defecto — la solución simple, fácil de cambiar. Este principio se suele llamar KISS — Keep It Simple, Stupid.

Reversibility — las decisiones difíciles de deshacer merecen más atención

En un restaurante puedes devolver un plato. Un «sí» en una boda no se devuelve.

No todas las decisiones arquitectónicas cuestan lo mismo si resultan erróneas. Elegir un lenguaje de programación o una base de datos es casi irreversible. Elegir una biblioteca de logs se revierte en un día. El arquitecto dedica un tiempo desproporcionado a las decisiones irreversibles y avanza rápido en las reversibles. En la industria suelen llamarlas one-way door (puerta de un solo sentido) y two-way door (puerta de doble sentido).

Technical Debt — una elección consciente, no pereza

Un crédito de negocio está bien si sabes cuándo y cómo lo vas a devolver. Un crédito sin plan de pago es el camino a la quiebra.

A veces lo correcto ahora es entregar algo que tendrás que reescribir después. Eso es technical debt (deuda técnica). Y es normal. Lo que no es normal es no reconocer que es una deuda. El arquitecto anota qué trade-offs se tomaron, por qué, y cuándo hay que volver a ellos.

Decomposition — la habilidad central del arquitecto

No puedes comerte una ballena entera. Sí puedes — si la cortas en trozos que te caben en la boca.

Un sistema grande es incomprensible. Decomposition es la habilidad de cortarlo en partes. Una buena arquitectura es un conjunto de partes pequeñas, cada una comprensible por sí sola. Si para explicar un componente hay que traer otros tres — la descomposición es mala.

Cohesion & Coupling — alta cohesión por dentro, bajo acoplamiento por fuera

Un buen departamento: la cocina está organizada en torno a un solo propósito (la estufa junto al fregadero) y comparte con los vecinos una sola pared.

Dentro de un módulo todo debe tratar de una sola cosa — eso es alta cohesión. Entre módulos — el mínimo contacto, a través de una interfaz clara — eso es bajo acoplamiento. Si cambias algo en un módulo y tienes que tocar otros cinco — el acoplamiento entre ellos es demasiado alto.

Layers & the Dependency Rule — las capas tratan de la dirección de las dependencias

Los pisos de una casa: el tercero se apoya en el segundo, el segundo en el primero, el primero en los cimientos. No se pueden poner los cimientos sobre el tercer piso.

En una buena arquitectura, la lógica de negocio no sabe nada de la base de datos, la interfaz web ni el framework. Las capas internas no dependen de las externas — esa es la dependency rule (regla de dependencia). Cuando hay que cambiar la base de datos o el framework, la lógica de negocio no se toca. Eso es Clean Architecture en una frase.

Interface over Implementation — importa más la interfaz

No te importa qué marca de ascensor hay en el edificio. Te importa que los botones funcionen igual, que las puertas abran con fiabilidad y que sea silencioso.

Cuando un módulo habla con otro, lo que importa es el contrato entre ellos (la interfaz), no cómo está construido por dentro el otro (la implementación). Primero se diseña la frontera (API, interfaz de clase, esquema de mensajes), luego la implementación. Las implementaciones se cambian con libertad; los contratos, solo siendo plenamente consciente del costo.

Monolith vs Microservices — cuestión de madurez, no de moda

Un cocinero en una cocina pequeña hace un plato más rápido que diez cocineros negociando por Slack. Con cien platos por hora, diez cocineros lo hacen mejor.

Un monolito es una aplicación que se despliega entera. Los microservicios son muchos servicios pequeños, cada uno con su propio despliegue. Los microservicios resuelven problemas de escala organizativa y de carga, no de calidad del código. Un equipo pequeño con microservicios es una complejidad que nadie pidió. El arquitecto empieza con un monolito y lo divide cuando aparece dolor real, no «porque está de moda».

Data Model — sobrevive a todo lo demás

Los cimientos de una casa sobreviven a todas las paredes y tejados que se construyen sobre ellos durante un siglo.

Los lenguajes se irán, los frameworks cambiarán, la interfaz se redibujará diez veces. El modelo de datos que se pone al principio se queda — porque cambiarlo en un sistema en marcha es carísimo. Es lo primero en lo que el arquitecto invierte tiempo y lo último que se apura a corregir.

Single Source of Truth — cada dato vive en un solo lugar

Si cada miembro de la familia lleva su propia lista de compras, dos comprarán leche y nadie comprará pan.

La misma información en dos lugares es un camino seguro hacia la divergencia. El principio de single source of truth (SSOT): el arquitecto determina dónde vive cada dato del sistema. Si los datos se duplican (por rendimiento, por ejemplo), debe quedar explícito qué es la fuente de verdad y qué es una caché o una proyección.

State — complejidad; cuanto menos, mejor

Un escritorio despejado facilita el trabajo. Uno desordenado te obliga a recordar dónde está cada cosa y te distrae todo el tiempo.

Cada pieza de estado guardada en algún lugar es algo que puede desincronizarse, perderse o contradecir a otro estado. La buena arquitectura apunta a funciones sin memoria (stateless) y variables de vida corta. El estado queda donde de verdad hace falta — normalmente en la base de datos.

Transactions — la atomicidad de la intención

Una transferencia de dinero son dos acciones pero una sola intención. O ocurrieron las dos escrituras, o ninguna. A medias es una catástrofe.

Cuando varios cambios deben ocurrir como una sola unidad, hacen falta transacciones. Esa propiedad se llama atomicidad. El arquitecto sabe qué operaciones del sistema son atómicas, cuáles pueden fallar a medias y cómo convivir con eso. En los sistemas distribuidos esto se vuelve un problema central (two-phase commit, sagas, idempotency).

Cache — una segunda verdad, y puede mentir

El calendario del refrigerador es más rápido que mirar el teléfono. Pero si alguien cambió el horario en el teléfono — el refrigerador ya está mintiendo.

Una caché da velocidad pero quita la garantía de frescura. El arquitecto siempre entiende: qué se cachea, por cuánto tiempo y qué pasa si la caché miente. La pregunta más difícil sobre una caché no es cómo agregarla — es cómo invalidarla (cache invalidation).

API Contract — la frontera de un sistema es un contrato, no código

La frontera entre países no es una valla — son las reglas: qué se puede cruzar, quién entra, qué pasaporte hace falta.

Una API, un esquema de mensajes, un formato de archivo — son una promesa a todos los que los usan. Cambiar el contrato es cambiar la promesa, y eso cuesta mucho. Un buen arquitecto diseña los contratos para poder ampliarlos sin romper a los clientes existentes (añadir campos, nunca quitarlos). Esa propiedad se llama backward compatibility (compatibilidad hacia atrás).

Sync vs Async — una elección de acoplamiento en el tiempo

Una llamada telefónica: ambos tienen que estar en línea al mismo tiempo. Una carta: el destinatario la lee cuando le conviene.

Una llamada síncrona acopla dos servicios en el tiempo: si el receptor está caído, el emisor también se atasca. La mensajería asíncrona a través de una cola rompe ese acoplamiento: el emisor deja la carta y sigue. Eso da resiliencia pero añade complejidad — retrasos, duplicados, orden.

Idempotency — una operación se puede repetir sin riesgo

Se llama al ascensor al tercer piso. Si diez personas vuelven a pulsar el mismo botón, el ascensor sigue yendo al tercer piso y no se rompe nada.

En los sistemas reales las llamadas se reintentan — por timeouts, fallos de red, reinicios. Una operación idempotente da el mismo resultado al repetirse. Una operación peligrosa de reintentar es una bomba de tiempo. El arquitecto hace idempotentes por defecto las operaciones críticas (pagos, procesamiento de mensajes).

External Dependencies — siempre un riesgo

Si la cena depende de la pizzería de enfrente — no pasa nada, hay alternativas. Si depende del único proveedor de carne de la ciudad — es crítico.

Toda dependencia externa — API, servicio, biblioteca — puede caerse, volverse lenta o cambiar su contrato. El arquitecto decide qué pasará cuando eso ocurra: ¿cae todo el sistema, o sigue funcionando con degradación? Muchas veces conviene aislar la dependencia externa detrás de una capa propia (un adapter) — para poder cambiarla después.

Security — no es una función, es una forma de vida del sistema

En un museo, la seguridad no es una cámara en la puerta — son capas: torniquetes, guardias, cámaras en cada sala, cerraduras en las vitrinas.

La seguridad no se puede añadir al final. Se construye en cada capa: autenticación, autorización, cifrado, aislamiento, auditoría, mínimo privilegio. Este enfoque por capas se llama defense in depth. El arquitecto piensa en ella desde el primer día y en cada decisión pregunta: «¿Y si un atacante entra por aquí?»

Un taxi para tres personas no debe viajar como un tren bala. Un tren bala no cabe por una calle lateral.

«Hazlo rápido» es un requisito sin sentido. El arquitecto expresa el rendimiento en números: cuántas peticiones por segundo (throughput), qué latencia es tolerable, cómo se comporta el sistema en el pico, qué pasa al pasar el límite. Optimizar demasiado pronto es un desperdicio; no pensar en absoluto es una catástrofe.

Scalability — la capacidad de crecer sin reescribir

Una casa diseñada con la opción de añadir un segundo piso se amplía sin demoler. Una casa sin esa opción — solo reconstruyéndola desde cero.

Scalability: el sistema debe crecer en dos direcciones — más usuarios (horizontalmente — añadir servidores) y más funciones (de forma modular — añadir módulos sin romper los viejos). Eso se incorpora al diseño, no se añade después.

Reliability — el comportamiento del sistema cuando algo se rompe

Un buen barco no es el que no se hunde (esos no existen) — es el que tiene diez compartimentos, de modo que si se perfora uno, los demás siguen a flote.

Cada parte de un sistema termina por romperse. Reliability no es «nunca se rompe» — es «sobrevive a la rotura». El arquitecto no intenta evitar el fallo — diseña cómo sobrevive el sistema: aislamiento de fallos, reintentos, degradación elegante, fallbacks. La regla principal: el fallo de un componente no debe matar todo el sistema.

Observability — no puedes arreglar lo que no ves

Un coche sin indicador de combustible, sin termómetro, sin indicador de presión de aceite. Anda hasta que muere para siempre.

Observability: el sistema debe contarte su propio estado — logs, métricas, trazas. Cuando algo sale mal a las tres de la mañana, tienes minutos para encontrar el problema. Si la observabilidad no se diseña desde el principio, ya es tarde para añadirla — ni siquiera sabes dónde mirar.

Evolvability — estar listo para el cambio importa más que tener razón hoy

En una ciudad nueva, las calles se hacen más anchas de lo que hoy hace falta. Diez años después hay más coches, y las calles estrechas habría que levantarlas.

El arquitecto no intenta predecir cada función futura (es imposible). Deja la opción de añadir funciones sin romper lo existente. Esa propiedad se llama evolvability. En la práctica significa: fronteras claras, contratos extensibles, separar el «qué» del «cómo».

Mudarse de una casa vieja a una nueva es un proceso de meses. No puedes tirar todo y volver a comprarlo todo.

Cuando un sistema necesita cambiar (nueva base de datos, nuevo protocolo, nuevo modelo de datos) — eso no es «reescribir desde cero», es «llevar el sistema a través de una transición». Eso es una migration. Los sistemas reales funcionan durante los cambios. El arquitecto piensa en el camino de la migración desde el principio; si no, la transición se vuelve imposible.

YAGNI & Deletion — borrar importa más que añadir

Un armario no se puede ampliar para siempre. A veces hay que tirar lo viejo para hacer sitio a lo nuevo.

Todo sistema exitoso acumula código muerto, funciones sin uso, integraciones obsoletas. Es un impuesto que cada desarrollador paga todos los días. El arquitecto se pregunta con regularidad: «¿Qué podemos borrar?» — y a veces esa es la decisión arquitectónica más útil del año.

El muro más fuerte es el que nunca hubo que derribar, porque nada superfluo quedó encajado detrás de él.

A veces la decisión arquitectónica correcta es no tomar una decisión arquitectónica. No introducir una capa de abstracción «para el futuro». No dividir el monolito «porque algún día». No construir un sistema de plugins «por si acaso». El principio se llama YAGNI — You Aren't Gonna Need It (no lo vas a necesitar). Un buen arquitecto sabe cuándo decir «todavía no» o «esto no hace falta».

ADR — una decisión arquitectónica se anota, o se pierde

Un testamento oral muere con su autor. Uno escrito sobrevive a generaciones.

Toda decisión arquitectónica importante debe registrarse: qué se eligió, cuáles eran las alternativas, por qué se descartaron, qué compromisos se aceptaron. El documento no hace falta ahora — hace falta dentro de un año, cuando llega una persona nueva y pregunta «¿por qué esto está hecho de una forma tan rara?». El formato estándar es el ADR (Architecture Decision Record).

C4 Model — un diagrama vale más que mil palabras

Describir con palabras cómo llegar a una casa es largo y a menudo inútil. Mostrar un mapa lleva un segundo.

El arquitecto siempre tiene un diagrama del sistema: qué componentes hay, cómo se conectan, dónde están las fronteras. No perfecto — funcional. Sirve para explicar rápido a una persona nueva y para ver el sistema entero. El modelo C4 (Context, Container, Component, Code) es simple y suficiente para la mayoría de los casos.

Un buen médico explica el diagnóstico al paciente con palabras que este entiende. Uno malo usa términos médicos tras los cuales el paciente asiente y no entiende nada.

Si el arquitecto solo sabe explicar una decisión a otros ingenieros, se ha perdido la mitad del trabajo. Negocio, producto, legal, seguridad — todos los stakeholders necesitan entender las consecuencias. Traducir una decisión técnica al lenguaje del negocio (costo, riesgo, tiempo) es una de las habilidades centrales del arquitecto.

Un cirujano que acepta todas las peticiones pierde pacientes. Uno bueno se niega cuando la operación mataría.

El equipo a menudo pide decisiones que suenan razonables pero crean problemas a largo plazo. El arquitecto tiene que saber negarse, explicar el riesgo y a veces mantener su postura — aunque sea impopular. Y también — saber admitir que se equivoca y cambiar la decisión cuando el contraargumento es más fuerte.

Cómo se conectan los conceptos

Una caja de herramientas: un martillo es inútil sin clavos, y los clavos sin martillo.

Los conceptos del curso no viven solos. Una decisión empieza con Problem Framing, se sopesa como un Trade-off, se revisa su Reversibility y se anota en un ADR. Un sistema se corta con Decomposition, el corte se juzga con Cohesion & Coupling, y las partes se encuentran en una Interface. Las copias de los datos viven bajo una Single Source of Truth, y los reintentos en un mundo async exigen Idempotency.