#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.
Día 27: El reloj es una entrada del dominio, no del ambiente
El cliente pagó a las 23:40 y el sistema lo rechazó: el servidor corre en UTC. El reloj es una entrada del dominio que nadie declaró. #100ArchitectureDays
Día 26: Qué cuidar depende de lo que no puedes 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
Día 25: Cada mock que escribes 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
Día 24: 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.
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.