¡Casi último capítulo! Esta vez estamos hablaremos de Arquitectura Software:

• Simplicidad ante todo: Por qué en Uber no usaban UML ni herramientas complicadas - solo pizarra, cajas y flechas. La buena arquitectura no viene de herramientas "fancy" sino de decisiones pragmáticas

• 1-way doors vs 2-way doors: El framework de Amazon para categorizar decisiones - desde cambios reversibles (A/B tests, linters) hasta compromisos mayores (cloud provider, arquitectura completa)
• Deuda de arquitectura y radio de explosión: Los costes ocultos de las malas decisiones arquitectónicas y cómo medir el impacto real de tus cambios (spoiler: deprecar APIs públicas no es lo mismo que refactorizar código interno)
• Arquitectura alineada con negocio: Por qué la arquitectura existe para servir al negocio, no al revés. Cuándo una arquitectura "mala" puede estar bien y cómo aprovechar cambios de negocio para mejorar la técnica
• "Bueno" mejor que "perfecto": La obsesión por la arquitectura perfecta puede cerrarte puertas futuras. Better done than perfect, pero sabiendo qué es "suficientemente bueno"
• Tipos de arquitectos: Desde el teórico en su "torre de marfil" hasta la "máquina de programar" - por qué los mejores equipos combinan ambos perfiles con respeto mutuo

Enlaces:

• https://www.oreilly.com/library/view/foundations-of-scalable/9781098106058/
• https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/