#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.
Testing que de verdad importa
Tests que atrapan bugs, no que inflan coverage.
- TDD
- Test doubles
- Testcontainers
- Contract testing
El resto del recorrido
Clean Code y principios de diseño
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.
Qué cuidar depende de lo que no podés permitirte que falle
El peor error del súper se arregla con una nota de crédito. En salud no hay rollback. Eso decide qué testear, no el catálogo de tests. #100ArchitectureDays
Cada mock que escribís es una dependencia que no invertiste
Probar una multiplicación te cuesta levantar Docker, correr migraciones y esperar 40 segundos. El problema no es cuántos mocks tenés: es dónde están parados. #100ArchitectureDays
Escribir código dejó de ser el cuello de botella. Verificarlo, no.
Probás que 2 + 2 da 4. ¿Probaste alguna vez que tu sistema cumple con la arquitectura que definiste? Nadie lo hace, y ese hueco se paga en cada PR. #100ArchitectureDays
Checkpoint Día 23: el mapa de los 10 principios de Clean Code
10 principios de clean code no son 10 reglas sueltas. Son un mapa. Cómo SRP, SOLID, naming, YAGNI y composición atacan el mismo problema raíz. #100ArchitectureDays.
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.
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.