#100ArchitectureDays
100 días para aprender arquitectura de software desde decisiones reales: código, trade-offs, errores comunes y sistemas que tienen que funcionar cuando dejan de ser una demo.
La arquitectura no se aprende memorizando patrones.
Se aprende entendiendo por qué una decisión parece buena al principio, cómo falla cuando el sistema crece y qué trade-off estás aceptando cuando la corregís. #100ArchitectureDays existe para eso: estudiar arquitectura desde problemas reales, no desde definiciones bonitas.
No hace falta leerla en orden
Elegí una ruta según tu problema actual: fundamentos, producción, código, liderazgo o IA. No estás obligado a completar los 100 días para llevarte valor.
Si estás empezando
Leé los días introductorios y los checkpoints. Te dan lenguaje y criterio para todo lo demás.
Si querés código
Buscá los días marcados como 🔧: ejercicios con versión antes/después y métricas.
Si querés decisiones
Buscá los días de trade-offs (⚖️) y ADRs (📐). Ahí vive el criterio arquitectónico.
Si venís por producción
Buscá logs, performance, resiliencia, bases de datos y observabilidad.
12 temporadas, una columna vertebral
La serie abrió con 15 días de fundamentos. A partir del día 16 se organiza en temporadas que van de los principios a la IA aplicada.
Clean Code y principios de diseño
Los principios que no caducan, aplicados a código real.
- Open/Closed
- Liskov
- Dependency Inversion
- Naming
- YAGNI
El resto del recorrido
Testing que de verdad importa
Modelar el dominio: DDD aplicado
Diseño de datos y persistencia
APIs y contratos
Estilos de arquitectura
Resiliencia y sistemas distribuidos
Observabilidad y operación
CI/CD y entrega
Seguridad para ingenieros
Comunicación y decisiones técnicas
Ingeniería asistida por IA
La ruta recomendada para empezar
Si llegás por primera vez, estos tres días te dan el lenguaje base de la serie.
Día 1: Tu app tarda 11 segundos en arrancar y vos pensás que es normal
De 10.7s a 1.3s de startup. El problema no es Spring Boot — es cómo inicializás tus servicios. Día 1 de #100ArchitectureDays.
Día 2: El SELECT * que arruinó tu API (y vos ni te enteraste)
Tu API responde en 10 segundos porque estás trayendo columnas que nadie necesita. Día 2 de #100ArchitectureDays.
Día 3: Agregaste un índice y la consulta sigue lenta. El problema no era el índice.
EXPLAIN ANALYZE es tu mejor amigo. Aprende a leer un query plan antes de optimizar a ciegas. Día 3 de #100ArchitectureDays.
Últimos días publicados
La serie está viva. Estas son las entregas más recientes.
Día 22: el método(true, false, true) que nadie entiende
Un boolean en la firma casi siempre significa que el método hace dos cosas. Tres técnicas para eliminar flag arguments en Java. #100ArchitectureDays.
Día 21: extends te encierra — composición te libera
Visa Infinite rompió una jerarquía de 4 niveles: Level-5, flag o copy-paste, todas trampas. La composición gana sobre la herencia. #100ArchitectureDays.
Día 20: YAGNI — la feature que programaste por las dudas
7 clases para un solo método de pago. PayPal y Crypto: TODO. Borró 300 líneas, todo siguió funcionando. Día 20 de #100ArchitectureDays.
Día 19: data, manager, process y otros crímenes
El código se lee 10x más de lo que se escribe. Cada nombre vago que te ahorra 2 segundos al escribir le cuesta 30 a cada lector. Día 19 de #100ArchitectureDays.
Día 18: Cambiar de proveedor sin tocar el core
ReportService tenía el proveedor hardcodeado. Cambiar a SMS exigía abrir el core. DIP: depende de la abstracción, no del proveedor. #100ArchitectureDays.
Día 17: Liskov, cuando heredar miente
Penguin extends Bird. En runtime, fly() explota. LSP: la herencia biologica no es herencia de comportamiento. Dia 17 de #100ArchitectureDays.
No mostramos código perfecto. Mostramos una decisión mala y cómo se corrige.
Algunos días incluyen ejercicios con versión antes/después: una decisión que parece buena, por qué duele cuando el sistema crece, y la corrección con su trade-off explícito.
Si la serie te ayuda, dejá una ⭐ en el repo. Ayuda a que más developers encuentren ingeniería sin filtros.
Ver repo en GitHub# cada ejercicio sigue la misma forma
problema → el síntoma en producción
antes → la decisión que parecía buena
después → la corrección, con su porqué
métricas → qué cambió, medido
La arquitectura no se aprende en una tarde.
Pero si leés una decisión por día, durante 100 días, vas a empezar a ver los sistemas de otra manera.