# Be Software Architecture Wise

> Un curso en línea completo de arquitectura de software, a tu propio ritmo, de Be Wise (bewiseapps.com): trece capítulos y 104 secciones, desde cómo funciona el software hasta la arquitectura de sistemas con IA. Edición en español: cada capítulo tiene una introducción en video y cada sección una videolección breve, narradas en inglés con subtítulos en español y transcripción. Las pruebas de capítulo opcionales, un examen final y un caso práctico de arquitectura conducen a un Certificado de Finalización de Be Wise (no acreditado). Información educativa, no asesoramiento profesional.

## Acerca del curso

- **¿Qué es Be Software Architecture Wise?** Un curso en línea completo de arquitectura de software, en 13 capítulos y 104 secciones, con 117 videolecciones narradas en inglés con subtítulos en español, desde cómo funciona el software hasta la arquitectura de sistemas con IA, con pruebas de capítulo opcionales, una evaluación final y un caso práctico, y un Certificado de Finalización Be Wise verificable.
- **¿A quién va dirigido el curso?** Principiantes sin formación técnica, desarrolladores que avanzan hacia puestos sénior, de liderazgo técnico o de arquitectura, arquitectos con experiencia que quieren un repaso estructurado, responsables de ingeniería y de producto, ingenieros de IA y estudiantes.
- **¿Qué necesito antes de empezar?** Ningún conocimiento previo; solo un teléfono, una tableta o una computadora con un navegador web moderno, una conexión a internet para las pruebas y ArchitectBot, y soltura para leer en español (los videos están narrados en inglés, con subtítulos en español).
- **¿Qué abarca el curso?** Trece capítulos: cómo funciona el software; qué es la arquitectura; atributos de calidad; principios de diseño; documentar la arquitectura; estilos monolíticos y diseño guiado por el dominio; sistemas distribuidos; arquitectura de datos; seguridad, privacidad y cumplimiento; rendimiento, resiliencia y operabilidad; infraestructura nativa de la nube; evaluación y gobernanza; y sistemas con IA.
- **¿Cómo está organizado el curso y cuánto tiempo lleva?** Cada capítulo tiene una introducción en video narrada, una vista general y ocho secciones, cada una con una videolección narrada, una explicación sencilla, los puntos clave, el desarrollo completo con diagramas y ejemplos prácticos, preguntas de autoevaluación y fuentes. Unas 40 horas de lectura, y unas 60 horas en total con las pruebas y el caso práctico, completamente a tu propio ritmo. Las 117 videolecciones suman unas 10 horas en total.
- **¿Cómo funcionan las pruebas de capítulo?** Cada prueba del capítulo tiene 20 preguntas de opción múltiple elegidas de un banco de 64 y 2 respuestas escritas que corrige una IA según criterios publicados. Las preguntas de opción múltiple valen el 70% y las respuestas escritas el 30%. La nota de aprobado es un 80% en total con al menos 2 de 5 en cada respuesta escrita. Intentos ilimitados pasados 10 minutos, con preguntas distintas.
- **¿Qué es la evaluación final?** Tras superar las 13 pruebas de capítulo: un examen final de 60 preguntas (nota de aprobado: 70%) y un caso práctico de arquitectura escrito de 1500 a 4000 palabras, calificado sobre 50 según una rúbrica publicada de cinco partes (nota de aprobado: 25).
- **¿Cómo se calcula la calificación final?** Puntuación global = 40% de la media de las mejores puntuaciones en las pruebas de capítulo + 30% del examen final + 30% del caso práctico. Distinción: 90 o más en total y al menos un 80% en el caso práctico. Mérito: 80 o más. Aprobado: todas las partes superadas.
- **¿Qué muestra el certificado y cómo se puede comprobar?** Un Certificado de Finalización Be Wise que muestra tu nombre, la fecha, tu calificación (Aprobado, Mérito o Distinción) y un número único que cualquiera puede comprobar en línea.
- **¿Es el certificado una titulación oficial acreditada?** No. Acredita que completaste este curso y superaste sus evaluaciones. No está acreditado, no otorga créditos académicos y no lo emite ni lo respalda ninguna universidad, organismo profesional ni programa de certificación.
- **¿Qué ocurre con mis datos?** No hace falta cuenta. El progreso de lectura se queda en tu navegador; las puntuaciones de las pruebas se guardan asociadas a un código de continuación aleatorio, sin datos personales; tu nombre solo se guarda si solicitas un certificado, para que se pueda comprobar.
- **¿Qué es ArchitectBot?** El asistente de estudio con IA del curso. Responde primero a partir del curso y busca en la web información más reciente. Puede cometer errores y no responderá por ti las preguntas de las pruebas.
- **¿Cómo se mantiene el contenido exacto y actualizado?** Cada capítulo se comprueba frente a sus fuentes citadas antes de publicarse, las fuentes se indican en cada sección, los capítulos se actualizan cuando cambia la práctica y se pueden notificar errores.
- **¿Qué dispositivos puedo usar y es accesible?** Teléfonos, tabletas y computadoras con cualquier navegador actualizado; se puede instalar como app; todos los capítulos también como páginas web y en PDF; todos los videos están narrados en inglés y tienen subtítulos en español e inglés, una opción de solo audio y una transcripción; los diagramas tienen descripciones de texto.
- **Lo que el curso no es** Es información educativa, no asesoramiento profesional; no es una titulación oficial acreditada ni una preparación para exámenes; no está afiliado a ninguna universidad ni organismo de certificación; no es un curso de programación; y no tiene clases en directo, aunque cada capítulo y sección tiene una videolección narrada.
- **¿Cuánto cuesta?** En la actualidad, todo el curso es gratuito: todos los capítulos, las pruebas de capítulo, ArchitectBot, la evaluación final y el certificado. Si eso cambia, el precio y exactamente lo que incluye se mostrarán en esta página antes de que empieces algo que sea de pago.
- Más información: https://bewiseapps.com/es/software-architecture-wise/about-the-course

## Capítulos y secciones

### [Capítulo 0: Empieza aquí: cómo funciona el software](https://bewiseapps.com/es/software-architecture-wise/foundations/)
Principiante. La base de todo lo que sigue: qué es un programa, cómo se organizan los datos y el código, cómo se comunican las computadoras a través de las redes, dónde se almacenan los datos, qué son las API, los servidores y la nube, y cómo construyen software los equipos. No se presupone ningún conocimiento previo.

- [0.1 Programas, código y cómo los ejecuta una computadora](https://bewiseapps.com/es/software-architecture-wise/foundations/what-software-is): Qué son el hardware y el software, cómo el código fuente se convierte en instrucciones que un procesador puede ejecutar, qué hace el sistema operativo y qué ocurre realmente, paso a paso, cuando se ejecuta un pequeño programa en Python.
- [0.2 Datos, estructuras de datos y algoritmos, y por qué la velocidad depende de ellos](https://bewiseapps.com/es/software-architecture-wise/foundations/data-and-algorithms): Cómo representan las computadoras los números y el texto, las estructuras de datos de uso diario (listas, diccionarios, colas, árboles, grafos), qué es un algoritmo y cómo la notación Big-O explica por qué algunos sistemas se vuelven más lentos a medida que crecen los datos.
- [0.3 Funciones, módulos, objetos, interfaces, bibliotecas y frameworks](https://bewiseapps.com/es/software-architecture-wise/foundations/organising-code): Cómo dividen los programadores el código en funciones, módulos, objetos e interfaces; la diferencia entre una biblioteca y un framework; los beneficios y los riesgos de las dependencias; y un primer vistazo al acoplamiento y la cohesión.
- [0.4 Redes, internet y la web: IP, DNS, HTTP y el modelo cliente-servidor](https://bewiseapps.com/es/software-architecture-wise/foundations/how-computers-talk): Cómo viajan los datos por internet en paquetes, qué hacen las direcciones IP, los puertos, TCP, UDP y DNS, cómo funcionan las solicitudes HTTP y HTTPS, por qué la física impone un límite mínimo a la latencia y qué ocurre cuando escribes una dirección web.
- [0.5 Archivos y bases de datos: almacenamiento relacional y no relacional, consultas y transacciones](https://bewiseapps.com/es/software-architecture-wise/foundations/storing-data): Por qué los sistemas necesitan bases de datos y no simples archivos, cómo funcionan las tablas relacionales, las claves, SQL, los índices y las transacciones ACID, las principales familias NoSQL y por qué hay que probar las copias de seguridad.
- [0.6 Las API, JSON y cómo trabajan juntos sistemas separados](https://bewiseapps.com/es/software-architecture-wise/foundations/apis-and-integration): Qué es una API y por qué es un contrato, cómo usan las API REST las URL, los verbos HTTP, los códigos de estado y JSON, y cómo las claves, los webhooks, las colas, las versiones y los límites de tasa determinan la integración.
- [0.7 Servidores, sistemas operativos, máquinas virtuales, contenedores y servicios en la nube](https://bewiseapps.com/es/software-architecture-wise/foundations/servers-and-the-cloud): Qué son los servidores y los centros de datos, cómo comparten el hardware las máquinas virtuales y los contenedores, qué delegan en el proveedor IaaS, PaaS, SaaS y serverless, y cómo encajan las regiones, las zonas, las CDN y el escalado.
- [0.8 Requisitos, control de versiones, pruebas, entrega y el recorrido de una solicitud](https://bewiseapps.com/es/software-architecture-wise/foundations/how-software-gets-built): Cómo convierten los equipos las necesidades en historias de usuario, colaboran con Git y pull requests, prueban a varios niveles y entregan mediante CI/CD y entornos, y cómo un toque en una app de reparto de comida atraviesa todas las partes de un sistema.

### [Capítulo 1: Qué es la arquitectura de software](https://bewiseapps.com/es/software-architecture-wise/what-is-architecture/)
De principiante a intermedio. Las definiciones que importan (ISO/IEC/IEEE 42010 y el SEI), en qué se diferencia la arquitectura del diseño, por qué determina el costo y el riesgo, qué hacen realmente los arquitectos, las partes interesadas, los compromisos, la deuda técnica y el lugar de la arquitectura en la entrega moderna.

- [1.1 Qué es la arquitectura de software: las definiciones estándar y lo que tienen en común](https://bewiseapps.com/es/software-architecture-wise/what-is-architecture/defining-architecture): La norma internacional, el SEI y los profesionales más destacados definen la arquitectura de software de forma distinta. Aprende las definiciones principales, lo que tienen en común y los tres tipos de estructura que tiene todo sistema.
- [1.2 Arquitectura, diseño y código: significancia, alcance y niveles](https://bewiseapps.com/es/software-architecture-wise/what-is-architecture/architecture-vs-design): La arquitectura y el diseño forman un único continuo de decisiones. Aprende qué hace que una decisión sea arquitectónicamente significativa, en qué se diferencian las decisiones estratégicas y las tácticas, y cómo se relacionan la arquitectura empresarial, la de soluciones y la de software.
- [1.3 Por qué importa la arquitectura: costo del cambio, calidad, riesgo y fallos reales](https://bewiseapps.com/es/software-architecture-wise/what-is-architecture/why-architecture-matters): La arquitectura determina las cualidades de un sistema, el costo y la velocidad de cada cambio futuro, sus riesgos y cómo pueden trabajar los equipos. Casos reales de Knight Capital, HealthCare.gov y Prime Video muestran por qué.
- [1.4 Qué hace un arquitecto: responsabilidades, habilidades y tipos de arquitecto](https://bewiseapps.com/es/software-architecture-wise/what-is-architecture/the-architect-role): Lo que hacen realmente los arquitectos en su día a día, las ocho expectativas descritas por Richards y Ford, los tipos de arquitecto, la amplitud frente a la profundidad y si los arquitectos deberían seguir escribiendo código.
- [1.5 Las partes interesadas, sus inquietudes y cómo las atiende la arquitectura](https://bewiseapps.com/es/software-architecture-wise/what-is-architecture/stakeholders-and-concerns): Quién tiene un interés en un sistema, qué entiende ISO/IEC/IEEE 42010 por inquietud, cómo identificar a las partes interesadas e implicarlas, y cómo las inquietudes en conflicto se convierten en requisitos, decisiones y vistas explícitos.
- [1.6 Decisiones arquitectónicas y compromisos: reversibilidad y momento oportuno](https://bewiseapps.com/es/software-architecture-wise/what-is-architecture/decisions-and-trade-offs): Por qué toda elección arquitectónica es un compromiso, cómo se estructura una decisión bien formada, las puertas de un solo sentido y de doble sentido, el último momento responsable, el diseño para la reversibilidad, las trampas cognitivas y la matriz de decisión ponderada.
- [1.7 Deuda técnica, erosión y deriva de la arquitectura](https://bewiseapps.com/es/software-architecture-wise/what-is-architecture/technical-debt): Lo que quería decir realmente la metáfora de la deuda de Ward Cunningham, el principal y los intereses, el cuadrante de la deuda de Fowler, por qué la deuda arquitectónica es la que más cuesta, la erosión y la deriva, y cómo detectar, gestionar y explicar la deuda en términos de negocio.
- [1.8 La arquitectura a lo largo del ciclo de vida: arquitectura inicial, emergente y continua](https://bewiseapps.com/es/software-architecture-wise/what-is-architecture/architecture-in-the-lifecycle): El gran diseño inicial (big design up front) frente al diseño emergente, lo que dice realmente el Manifiesto Ágil, el modelo dirigido por riesgos de Fairbanks, la arquitectura intencional y la pista arquitectónica (runway), la arquitectura continua, los esqueletos andantes, los spikes y la arquitectura en DevOps.

### [Capítulo 2: Atributos de calidad y requisitos arquitectónicamente significativos](https://bewiseapps.com/es/software-architecture-wise/quality-attributes/)
Intermedio. Cómo convertir deseos vagos como 'rápido' y 'seguro' en requisitos precisos y comprobables: ISO/IEC 25010, escenarios de atributos de calidad, rendimiento, disponibilidad, modificabilidad, seguridad y usabilidad, y cómo elicitarlos, priorizarlos y establecer compromisos entre ellos.

- [2.1 Requisitos funcionales, atributos de calidad y restricciones](https://bewiseapps.com/es/software-architecture-wise/quality-attributes/functional-vs-quality): Qué debe hacer un sistema, con qué calidad debe hacerlo y qué decisiones ya están fijadas. Aprende a detectar los requisitos arquitectónicamente significativos que realmente determinan un diseño.
- [2.2 Los modelos de calidad: ISO/IEC 25010 y cómo usarla](https://bewiseapps.com/es/software-architecture-wise/quality-attributes/the-quality-models): El modelo de calidad del producto de ISO/IEC 25010:2023 y sus nueve características, qué ha cambiado desde 2011, otras listas como FURPS+ y cómo usar un modelo como lista de comprobación sin ahogarse en papeleo.
- [2.3 Escribir escenarios de atributos de calidad que se puedan probar](https://bewiseapps.com/es/software-architecture-wise/quality-attributes/quality-attribute-scenarios): El escenario de seis partes que convierte 'rápido', 'seguro' y 'fácil de cambiar' en requisitos comprobables, con ejemplos para seis cualidades, los errores comunes y el camino del escenario a la función de aptitud.
- [2.4 Rendimiento y escalabilidad: latencia, rendimiento (throughput), percentiles y carga](https://bewiseapps.com/es/software-architecture-wise/quality-attributes/performance-and-scalability): La latencia y el rendimiento (throughput), los percentiles y la latencia de cola, la ley de Little, el encolamiento y el abismo de la utilización, la ley de Amdahl y la Ley de escalabilidad universal, con cálculos desarrollados y un panorama de las tácticas de rendimiento.
- [2.5 Disponibilidad y fiabilidad: nueves, MTBF, MTTR y tolerancia a fallos](https://bewiseapps.com/es/software-architecture-wise/quality-attributes/availability-and-reliability): Qué significan realmente la disponibilidad, la fiabilidad y la tolerancia a fallos, cómo calcular los nueves, el MTBF y el MTTR, cómo se combinan los componentes en serie y en paralelo, y las tácticas, el RTO y el RPO que las hacen posibles.
- [2.6 Modificabilidad, capacidad de prueba y desplegabilidad: diseñar para el cambio](https://bewiseapps.com/es/software-architecture-wise/quality-attributes/modifiability-testability-deployability): Cómo especificar el cambio y diseñar para él: qué cambia, quién lo cambia y cuándo, las tácticas que limitan los efectos en cadena, la capacidad de prueba mediante la controlabilidad y la observabilidad, la desplegabilidad y las métricas de entrega de DORA.
- [2.7 Seguridad, usabilidad, interoperabilidad, costo y sostenibilidad como cualidades](https://bewiseapps.com/es/software-architecture-wise/quality-attributes/security-usability-and-more): La seguridad como cualidad medible, las subcaracterísticas y tácticas de seguridad de ISO/IEC 25010, la usabilidad y la accesibilidad según WCAG 2.2, la interoperabilidad, el costo por transacción, la intensidad de carbono del software, la seguridad (safety), la observabilidad y las cualidades regulatorias.
- [2.8 Elicitación, priorización y compromisos entre atributos de calidad](https://bewiseapps.com/es/software-architecture-wise/quality-attributes/eliciting-and-prioritising): De dónde salen los requisitos de calidad, cómo el Quality Attribute Workshop del SEI y el árbol de utilidad de ATAM los descubren y los clasifican, cómo gestionar los conflictos entre cualidades y cómo las funciones de aptitud los mantienen vigentes.

### [Capítulo 3: Principios y fundamentos de diseño](https://bewiseapps.com/es/software-architecture-wise/design-principles/)
Intermedio. Los principios en los que se basa toda buena estructura: modularidad, acoplamiento y cohesión, ocultación de información, reglas de dependencia, SOLID a escala de componentes, connascence, ley de Conway, simplicidad y cómo medir la estructura.

- [3.1 Modularidad: dividir un sistema en partes](https://bewiseapps.com/es/software-architecture-wise/design-principles/modularity): Qué es un módulo a cualquier escala, por qué dividimos los sistemas en módulos, la regla de Parnas de descomponer según los cambios probables, los módulos lógicos frente a los de despliegue, la granularidad y cómo hacer cumplir los límites en el código.
- [3.2 Acoplamiento y cohesión](https://bewiseapps.com/es/software-architecture-wise/design-principles/coupling-and-cohesion): Las dos medidas más antiguas de una buena estructura: los niveles clásicos de acoplamiento y cohesión, el acoplamiento aferente y eferente, las formas adicionales de acoplamiento en los sistemas distribuidos y las tácticas para reducirlo, con un ejemplo práctico de refactorización.
- [3.3 Ocultación de información, abstracción e interfaces](https://bewiseapps.com/es/software-architecture-wise/design-principles/information-hiding-and-abstraction): Por qué los módulos deben ocultar decisiones, en qué se diferencia la ocultación de información del encapsulamiento, las interfaces como contratos y el diseño por contrato, las abstracciones con fugas, los módulos profundos, la ley de Hyrum y cómo mantener estables las API entre componentes.
- [3.4 Gestionar las dependencias: dirección, ciclos y estabilidad](https://bewiseapps.com/es/software-architecture-wise/design-principles/dependencies-and-layering): Hacia dónde deben apuntar las dependencias y por qué: los principios de dependencias acíclicas, de dependencias estables y de abstracciones estables de Robert C. Martin, las métricas de inestabilidad, grado de abstracción y distancia, cómo romper ciclos, la organización en capas y las comprobaciones automáticas de dependencias.
- [3.5 Los principios SOLID aplicados a los componentes](https://bewiseapps.com/es/software-architecture-wise/design-principles/solid-at-scale): Los cinco principios SOLID explicados con precisión, cada uno mostrado en Python y luego a escala de componentes y de servicios, más los principios de cohesión REP, CCP y CRP, su triángulo de tensiones y las críticas honestas a SOLID.
- [3.6 Connascence: una medida más fina del acoplamiento](https://bewiseapps.com/es/software-architecture-wise/design-principles/connascence): La connascence de Meilir Page-Jones pone nombre a los acuerdos ocultos entre las partes de un sistema, los clasifica por fuerza y los valora por localidad y grado, desde los parámetros posicionales hasta la temporización entre servicios.
- [3.7 La ley de Conway y la forma de las organizaciones](https://bewiseapps.com/es/software-architecture-wise/design-principles/conways-law): La observación de Melvin Conway de 1968 según la cual los sistemas copian la estructura de comunicación de las organizaciones que los diseñan, la evidencia de la investigación, la aritmética de las vías de comunicación, la maniobra inversa de Conway y la carga cognitiva del equipo.
- [3.8 Simplicidad, reversibilidad y medición de la estructura](https://bewiseapps.com/es/software-architecture-wise/design-principles/simplicity-and-measurement): La complejidad esencial y la accidental, KISS, YAGNI, DRY como conocimiento y no como texto, la reversibilidad como opción, y cómo medir la estructura con la complejidad ciclomática, LCOM, el acoplamiento de cambio y las funciones de aptitud sin caer en la ley de Goodhart.

### [Capítulo 4: Documentar y comunicar la arquitectura](https://bewiseapps.com/es/software-architecture-wise/documenting-architecture/)
Intermedio. Vistas y puntos de vista, el modelo C4, el UML que todavía importa, los registros de decisiones de arquitectura (ADR), arc42, los diagramas como código y cómo presentar la arquitectura a públicos técnicos y no técnicos.

- [4.1 Por qué y cuánto documentar](https://bewiseapps.com/es/software-architecture-wise/documenting-architecture/why-document): Quién lee la documentación de arquitectura y qué necesita cada lector, qué dice realmente el Manifiesto Ágil sobre los documentos, cómo decidir qué merece la pena poner por escrito y las reglas que mantienen útil la documentación.
- [4.2 Vistas y puntos de vista: ISO/IEC/IEEE 42010, 4+1 y Rozanski y Woods](https://bewiseapps.com/es/software-architecture-wise/documenting-architecture/views-and-viewpoints): Por qué un solo diagrama nunca basta: el modelo de ISO/IEC/IEEE 42010 de partes interesadas, inquietudes, puntos de vista y vistas, el 4+1 de Kruchten, los puntos de vista y las perspectivas de Rozanski y Woods, y cómo elegir las vistas que necesita un sistema.
- [4.3 El modelo C4: contexto, contenedores, componentes y código](https://bewiseapps.com/es/software-architecture-wise/documenting-architecture/the-c4-model): El modelo C4 de Simon Brown en la práctica: los cuatro niveles de zoom, qué es realmente un contenedor, las reglas de notación que hacen que los diagramas se expliquen solos y una plataforma de reparto de comida dibujada a nivel de contexto, de contenedores y de componentes.
- [4.4 Los diagramas UML que los arquitectos todavía usan](https://bewiseapps.com/es/software-architecture-wise/documenting-architecture/uml-essentials): La situación actual de UML, los modos de boceto, plano y lenguaje de programación de Fowler, y lo esencial de la notación de los seis diagramas que los arquitectos todavía usan, cada uno dibujado para la plataforma de reparto de comida.
- [4.5 Registros de decisiones de arquitectura (ADR)](https://bewiseapps.com/es/software-architecture-wise/documenting-architecture/architecture-decision-records): Cómo registrar las decisiones significativas para que sus razones perduren: el formato de Nygard, MADR y las declaraciones Y, los estados y la sustitución, dónde guardar los registros, qué merece uno, la revisión y los antipatrones.
- [4.6 arc42 y otras plantillas de documentación](https://bewiseapps.com/es/software-architecture-wise/documenting-architecture/arc42-and-templates): Las doce secciones de arc42, qué va en cada una y cuánto escribir para sistemas pequeños y grandes, un ejemplo de arc42-lite en una página, las plantillas del SEI y de IEEE 1016, y la conformidad con ISO/IEC/IEEE 42010.
- [4.7 Diagramas como código y cómo mantener la documentación al día](https://bewiseapps.com/es/software-architecture-wise/documenting-architecture/diagrams-as-code): Escribir diagramas como texto con PlantUML, Mermaid, Structurizr DSL y D2, las herramientas de dibujo frente a las de modelado, la generación de la documentación en el pipeline y los hábitos que la mantienen fiel a la realidad.
- [4.8 Comunicar la arquitectura a distintos públicos](https://bewiseapps.com/es/software-architecture-wise/documenting-architecture/communicating-architecture): Adaptar la arquitectura a directivos, responsables de producto, desarrolladores, operaciones, seguridad y auditores: explicar los compromisos, resúmenes de una página, seguir una solicitud, documentos de diseño y RFC, revisiones, diseño de diagramas y construcción de consensos.

### [Capítulo 5: Estilos arquitectónicos I: monolitos y diseños modulares](https://bewiseapps.com/es/software-architecture-wise/monolithic-styles/)
Intermedio. Estilos para sistemas que se despliegan como una sola unidad: en capas, monolito modular, tuberías y filtros, microkernel, arquitectura hexagonal y limpia, diseño guiado por el dominio, y cuándo un monolito es la respuesta correcta.

- [5.1 Estilos, patrones y tácticas arquitectónicos](https://bewiseapps.com/es/software-architecture-wise/monolithic-styles/what-is-a-style): El vocabulario de los dos capítulos siguientes: estilos, patrones, tácticas y arquitecturas de referencia, el particionamiento técnico frente al particionamiento por dominio, el despliegue monolítico frente al distribuido y el cuanto de arquitectura.
- [5.2 Arquitectura en capas](https://bewiseapps.com/es/software-architecture-wise/monolithic-styles/layered-architecture): El estilo más conocido: capas de presentación, de negocio, de persistencia y de base de datos. Capas cerradas y abiertas, capas de aislamiento, el antipatrón del sumidero, por qué cada funcionalidad toca todas las capas y cómo hacer cumplir las reglas.
- [5.3 El monolito modular](https://bewiseapps.com/es/software-architecture-wise/monolithic-styles/modular-monolith): Una única aplicación desplegable dividida por dominio de negocio en módulos con API explícitas y sus propios datos. Cómo hacer cumplir los límites, cómo se comunican los módulos, qué aprendió Shopify y cómo conserva la opción de extraer servicios más adelante.
- [5.4 Tuberías y filtros y arquitecturas de pipeline](https://bewiseapps.com/es/software-architecture-wise/monolithic-styles/pipes-and-filters): Datos que fluyen por una cadena de pasos independientes: productores, transformadores, verificadores y consumidores unidos por tuberías. De las tuberías de Unix a ETL, los compiladores y el procesamiento de flujos, con el rendimiento (throughput), el back pressure y la gestión de errores.
- [5.5 Arquitecturas de microkernel y de plug-ins](https://bewiseapps.com/es/software-architecture-wise/monolithic-styles/microkernel): Cómo un sistema central pequeño más plug-ins independientes ofrece extensibilidad: registros, contratos, aislamiento y versionado, ejemplos reales de IDE y navegadores, y un contrato de plug-in desarrollado para reglas fiscales específicas de cada país.
- [5.6 Arquitectura hexagonal, de cebolla y limpia](https://bewiseapps.com/es/software-architecture-wise/monolithic-styles/hexagonal-and-clean): Puertos y adaptadores, arquitectura de cebolla y limpia: mantener la lógica de negocio en el centro con las dependencias apuntando hacia dentro, puertos conductores y conducidos, un ejemplo en Python con un adaptador real y un doble de prueba, y los costos.
- [5.7 Diseño estratégico guiado por el dominio: contextos delimitados y mapas de contextos](https://bewiseapps.com/es/software-architecture-wise/monolithic-styles/domain-driven-design): Encontrar límites en el dominio de negocio: lenguaje ubicuo, subdominios centrales, de soporte y genéricos, contextos delimitados, relaciones del mapa de contextos, event storming, agregados y un mapa de contextos de la plataforma de reparto de comida.
- [5.8 Cuándo un monolito es la respuesta correcta](https://bewiseapps.com/es/software-architecture-wise/monolithic-styles/choosing-a-monolith): MonolithFirst, la prima de los microservicios y el monolito majestuoso; cuándo una sola unidad de despliegue es la opción correcta, hasta dónde escala un monolito, las señales de que ha llegado el momento de dividirlo y una guía de decisión para los estilos del Capítulo 5.

### [Capítulo 6: Estilos arquitectónicos II: sistemas distribuidos](https://bewiseapps.com/es/software-architecture-wise/distributed-systems/)
De intermedio a avanzado. Por qué y cuándo distribuir, las falacias de la computación distribuida, las arquitecturas basadas en servicios y de microservicios, los sistemas dirigidos por eventos, la comunicación síncrona y asíncrona, CAP y PACELC, las sagas y los diseños serverless y basados en espacios.

- [6.1 Por qué distribuir y las falacias de la computación distribuida](https://bewiseapps.com/es/software-architecture-wise/distributed-systems/why-distribute): Las razones reales para repartir un sistema entre varias máquinas, las ocho falacias que hacen la distribución más difícil de lo que parece, el fallo parcial, los costos y la aritmética de las cadenas de llamadas síncronas.
- [6.2 Arquitectura basada en servicios y arquitectura orientada a servicios](https://bewiseapps.com/es/software-architecture-wise/distributed-systems/service-based-and-soa): Servicios de dominio de grano grueso que comparten una base de datos, la época del bus de servicios empresarial en SOA y por qué se desvaneció, en qué se diferencian los microservicios, y cuándo la arquitectura basada en servicios es el término medio pragmático.
- [6.3 Microservicios: principios, beneficios y costos](https://bewiseapps.com/es/software-architecture-wise/distributed-systems/microservices): Qué son los microservicios según Lewis y Fowler, los contextos delimitados, la desplegabilidad independiente, la base de datos por servicio, los gateways y las mallas, cómo decidir la granularidad, los antipatrones clásicos y el precio organizativo.
- [6.4 Arquitectura dirigida por eventos: brokers, mediadores y flujos de eventos](https://bewiseapps.com/es/software-architecture-wise/distributed-systems/event-driven): Eventos, comandos y mensajes; las topologías de intermediario (broker) y de mediador; los cuatro patrones de eventos de Fowler; cómo funcionan las particiones, los offsets y los grupos de consumidores de Kafka; las garantías de entrega, los consumidores idempotentes, los esquemas y las colas de mensajes fallidos (dead-letter queues).
- [6.5 Comunicación síncrona y asíncrona: REST, gRPC, GraphQL y mensajería](https://bewiseapps.com/es/software-architecture-wise/distributed-systems/communication-and-apis): Cómo se comunican los servicios: el acoplamiento que crean la comunicación síncrona y la asíncrona, REST y la semántica de HTTP, gRPC, GraphQL y la mensajería, y las prácticas de diseño de API que permiten que las interfaces evolucionen sin romper a los consumidores.
- [6.6 Modelos de consistencia, CAP y PACELC](https://bewiseapps.com/es/software-architecture-wise/distributed-systems/consistency-cap-pacelc): Qué significa la consistencia para los datos replicados: los modelos, de linealizable a eventual, lo que dice realmente el teorema CAP y lo que no dice, el compromiso cotidiano de latencia de PACELC, la aritmética de los quórums y cómo elegir la consistencia para cada caso de uso.
- [6.7 Transacciones distribuidas, sagas y el patrón de bandeja de salida (outbox)](https://bewiseapps.com/es/software-architecture-wise/distributed-systems/sagas-and-distributed-transactions): Cómo mantener la consistencia de los datos cuando una acción de negocio abarca varios servicios: la confirmación en dos fases y por qué se evita, las sagas con compensaciones, la coreografía y la orquestación, las contramedidas de aislamiento, la bandeja de salida transaccional (transactional outbox) y los receptores idempotentes.
- [6.8 Arquitecturas serverless y basadas en espacios](https://bewiseapps.com/es/software-architecture-wise/distributed-systems/serverless-and-space-based): Dos respuestas opuestas a la capacidad: las funciones serverless y los backends gestionados que escalan a cero y se facturan por uso, y la arquitectura basada en espacios, que atiende picos extremos desde memoria replicada con la base de datos fuera de la ruta crítica.

### [Capítulo 7: Arquitectura de datos](https://bewiseapps.com/es/software-architecture-wise/data-architecture/)
De intermedio a avanzado. Propiedad de los datos, elección de una base de datos, transacciones y aislamiento, replicación y particionamiento, CQRS y event sourcing, caché, evolución de esquemas, y analítica, streaming y data mesh.

- [7.1 Propiedad de los datos y base de datos por servicio](https://bewiseapps.com/es/software-architecture-wise/data-architecture/data-ownership): Quién puede cambiar cada dato, por qué una base de datos compartida acopla los servicios, cómo resolver la propiedad conjunta, y cómo leer datos que no te pertenecen, elaborar informes sobre ellos y establecer contratos para usarlos.
- [7.2 Elegir una base de datos: relacional, documental, clave-valor, de columnas, de grafos y de series temporales](https://bewiseapps.com/es/software-architecture-wise/data-architecture/choosing-a-database): En qué es buena y en qué es mala cada familia de bases de datos, desde las relacionales hasta las vectoriales y el SQL distribuido, y cómo elegir según la forma de los datos, los patrones de acceso, la consistencia, la escala, la operación y las habilidades del equipo.
- [7.3 Transacciones, ACID y niveles de aislamiento](https://bewiseapps.com/es/software-architecture-wise/data-architecture/transactions-and-isolation): Qué garantiza realmente ACID, las anomalías que permiten los niveles de aislamiento, cómo funcionan MVCC y el aislamiento de instantánea (snapshot isolation), por qué engañan los nombres de los niveles y cuándo usar bloqueos, comprobaciones de versión o transacciones serializables.
- [7.4 Replicación, particionamiento y sharding](https://bewiseapps.com/es/software-architecture-wise/data-architecture/replication-and-partitioning): Cómo copian los datos las bases de datos para lograr disponibilidad y escalar las lecturas, qué efectos tienen el retardo de replicación y el failover en la corrección, y cómo el particionamiento por rango o por hash, el hashing consistente y los índices secundarios dan forma a un diseño con sharding.
- [7.5 CQRS y event sourcing](https://bewiseapps.com/es/software-architecture-wise/data-architecture/cqrs-and-event-sourcing): Separar el modelo que modifica los datos de los modelos que los leen, almacenar el estado como una secuencia de eventos de solo anexado (append-only) y los costos reales: consistencia eventual, versionado de eventos y datos personales.
- [7.6 Estrategias de caché y sus trampas](https://bewiseapps.com/es/software-architecture-wise/data-architecture/caching): Por qué las cachés aceleran los sistemas y qué cuestan: cache-aside, read-through, write-through, write-behind y refresh-ahead, TTL e invalidación, estampidas (stampedes), niveles de caché, cabeceras HTTP y desalojo (eviction).
- [7.7 Evolución de esquemas, migraciones y compatibilidad](https://bewiseapps.com/es/software-architecture-wise/data-architecture/schema-evolution): Cambiar los esquemas de bases de datos, API y eventos mientras el sistema sigue funcionando: compatibilidad hacia atrás, hacia adelante y completa, expandir y contraer, herramientas de migración, backfills de gran volumen y registros de esquemas para Avro y Protocol Buffers.
- [7.8 Analítica, streaming, almacenes de datos, lagos de datos y data mesh](https://bewiseapps.com/es/software-architecture-wise/data-architecture/analytics-and-streaming): Cómo se diseña la arquitectura de los datos analíticos: OLTP frente a OLAP, almacenes de datos (data warehouses) y esquemas en estrella, ETL y ELT, data lakes y lakehouses, procesamiento de flujos con tiempo del evento y marcas de agua (watermarks), Lambda y Kappa, y data mesh.

### [Capítulo 8: Seguridad, privacidad y cumplimiento desde el diseño](https://bewiseapps.com/es/software-architecture-wise/security-by-design/)
De intermedio a avanzado. Principios de seguridad, modelado de amenazas con STRIDE, identidad y acceso (OAuth 2.0 y OpenID Connect), cifrado y secretos, zero trust, seguridad de la cadena de suministro de software, privacidad desde el diseño según el RGPD (GDPR) y seguridad en operación.

- [8.1 Principios de seguridad para arquitectos](https://bewiseapps.com/es/software-architecture-wise/security-by-design/security-principles): La tríada CIA, los principios de diseño de Saltzer y Schroeder, la defensa en profundidad, la seguridad por defecto, la superficie de ataque y los límites de confianza, el OWASP Top 10 y un ciclo de vida de desarrollo seguro, con quién es responsable de qué.
- [8.2 Modelado de amenazas: STRIDE, árboles de ataque y diagramas de flujo de datos](https://bewiseapps.com/es/software-architecture-wise/security-by-design/threat-modelling): Las cuatro preguntas de Shostack, los diagramas de flujo de datos con límites de confianza, STRIDE y los árboles de ataque, cómo valorar el riesgo sin falsa precisión y un ejemplo práctico de modelo de amenazas del proceso de pago de una plataforma de reparto de comida.
- [8.3 Identidad y acceso: autenticación, autorización, OAuth 2.0 y OpenID Connect](https://bewiseapps.com/es/software-architecture-wise/security-by-design/identity-and-access): Autenticación frente a autorización, las reglas actuales del NIST sobre contraseñas, MFA y passkeys, sesiones y JWT, OAuth 2.0 con PKCE, OpenID Connect, RBAC, ABAC, control de acceso basado en relaciones e identidad de carga de trabajo.
- [8.4 Cifrado, gestión de claves y secretos](https://bewiseapps.com/es/software-architecture-wise/security-by-design/protecting-data): El cifrado en tránsito y en reposo y lo que protege realmente cada capa, la criptografía simétrica y asimétrica, el hash de contraseñas, KMS y el cifrado de sobre (envelope encryption), los secretos, la tokenización para PCI DSS y la clasificación de datos.
- [8.5 Comunicación segura y zero trust](https://bewiseapps.com/es/software-architecture-wise/security-by-design/zero-trust): Por qué fracasó la red interna de confianza, qué entienden NIST SP 800-207 y BeyondCorp por zero trust, y cómo lo llevan a la práctica mTLS, la identidad de carga de trabajo, las service meshes, los certificados y los gateways.
- [8.6 Seguridad de la cadena de suministro de software](https://bewiseapps.com/es/software-architecture-wise/security-by-design/supply-chain-security): Por qué las dependencias y los pipelines de compilación son una superficie de ataque, qué enseñan event-stream, SolarWinds, Log4Shell y xz utils, y cómo responden las SBOM, SLSA, Sigstore, la fijación de versiones (pinning) y el Reglamento de Ciberresiliencia de la UE (Cyber Resilience Act).
- [8.7 Privacidad desde el diseño y el RGPD (GDPR)](https://bewiseapps.com/es/software-architecture-wise/security-by-design/privacy-by-design): Cómo dan forma a la arquitectura el RGPD (GDPR) y el UK GDPR: los principios del artículo 5, la protección de datos desde el diseño y por defecto, los derechos que los sistemas deben respaldar, las EIPD, las transferencias, la seudonimización, y la conservación y supresión en todas las copias.
- [8.8 Seguridad en operación: logging, detección y respuesta](https://bewiseapps.com/es/software-architecture-wise/security-by-design/security-in-operation): Operar un sistema de forma segura: qué registrar y qué no registrar nunca, pistas de auditoría, detección con SIEM, gestión de vulnerabilidades con CVSS, EPSS y KEV, respuesta a incidentes según el NIST, copias de seguridad a prueba de ransomware y plazos de notificación de violaciones de datos.

### [Capítulo 9: Rendimiento, escalabilidad, resiliencia y operabilidad](https://bewiseapps.com/es/software-architecture-wise/resilience-and-operability/)
De intermedio a avanzado. Estrategias de escalado, balanceo de carga y ausencia de estado, colas y back pressure, timeouts, reintentos, circuit breakers y bulkheads, SLI, SLO y presupuestos de errores, observabilidad, planificación de capacidad e ingeniería del caos.

- [9.1 Estrategias de escalado: vertical, horizontal y el cubo de escalado](https://bewiseapps.com/es/software-architecture-wise/resilience-and-operability/scaling-strategies): El escalado vertical y horizontal y sus límites, el cubo de escalado de Abbott y Fisher, la ausencia de estado, el autoescalado reactivo, programado y predictivo, cómo elegir una señal de escalado, cómo evitar el flapping y cómo dimensionar una flota para un pico.
- [9.2 Balanceo de carga, ausencia de estado y sesiones](https://bewiseapps.com/es/software-architecture-wise/resilience-and-operability/load-balancing-and-statelessness): Balanceadores de carga de capa 4 y de capa 7, los principales algoritmos, incluido el poder de dos elecciones aleatorias, las comprobaciones de actividad (liveness) y de preparación (readiness), el drenaje de conexiones, los problemas de las sesiones persistentes (sticky sessions), el estado de sesión externalizado y el balanceo de carga global.
- [9.3 Asincronía, colas y back pressure](https://bewiseapps.com/es/software-architecture-wise/resilience-and-operability/queues-and-back-pressure): Cómo las colas convierten los picos en trabajo acumulado (backlog), los consumidores competidores, cómo dimensionar las colas con la ley de Little, el back pressure, el descarte de carga y la priorización, los limitadores de tasa token bucket y otros, HTTP 429 con Retry-After, y las colas de mensajes fallidos (dead-letter queues).
- [9.4 Timeouts, reintentos, circuit breakers, bulkheads y degradación elegante](https://bewiseapps.com/es/software-architecture-wise/resilience-and-operability/resilience-patterns): Los patrones de estabilidad que evitan que una dependencia lenta derribe todo un sistema: timeouts y plazos (deadlines), reintentos con backoff, jitter y presupuestos, circuit breakers, bulkheads, alternativas (fallbacks), idempotencia y solicitudes de cobertura (hedged requests).
- [9.5 SLI, SLO, SLA y presupuestos de errores](https://bewiseapps.com/es/software-architecture-wise/resilience-and-operability/slos-and-error-budgets): Cómo medir la fiabilidad desde el punto de vista del usuario con SLI, fijar objetivos de SLO, convertirlos en presupuestos y políticas de errores, alertar según la tasa de consumo (burn rate) y mantener los SLA, con margen, menos exigentes que los objetivos internos.
- [9.6 Observabilidad: logs, métricas y trazas](https://bewiseapps.com/es/software-architecture-wise/resilience-and-operability/observability): Cómo ver el interior de un sistema distribuido en ejecución: logs estructurados, tipos de métricas e histogramas, RED, USE y las señales doradas, trazado distribuido con W3C Trace Context y OpenTelemetry, cardinalidad y alertas basadas en síntomas.
- [9.7 Planificación de capacidad y pruebas de rendimiento](https://bewiseapps.com/es/software-architecture-wise/resilience-and-operability/capacity-and-performance-testing): Cómo planificar la capacidad antes de que llegue la demanda y comprobar que realmente está ahí: previsión, margen de capacidad (headroom) y plazos de entrega, pruebas de carga, de estrés, de resistencia (soak), de picos y de punto de ruptura, cargas de trabajo abiertas y cerradas, omisión coordinada y presupuestos de rendimiento.
- [9.8 Ingeniería del caos, incidentes y aprendizaje sin culpas](https://bewiseapps.com/es/software-architecture-wise/resilience-and-operability/chaos-and-incidents): Cómo encontrar las debilidades antes que los usuarios y aprender de los fallos que ocurren de todos modos: experimentos de caos y game days, coordinación de incidentes, niveles de gravedad y páginas de estado, revisiones sin culpas, los límites del MTTR y acciones que cambian el sistema.

### [Capítulo 10: Arquitectura nativa de la nube y de infraestructura](https://bewiseapps.com/es/software-architecture-wise/cloud-native/)
De intermedio a avanzado. Modelos de servicio en la nube, contenedores y Kubernetes, la aplicación de doce factores, infraestructura como código, CI/CD y estrategias de despliegue, multirregión y edge, ingeniería de plataformas, FinOps y la dependencia del proveedor (lock-in) como compromiso.

- [10.1 Modelos de servicio y de despliegue en la nube](https://bewiseapps.com/es/software-architecture-wise/cloud-native/cloud-models): IaaS, CaaS, PaaS, FaaS y SaaS; nube pública, privada, híbrida y multinube; responsabilidad compartida, zonas y servicios gestionados; qué significa nativo de la nube y cuándo alquilar no sale más barato.
- [10.2 Contenedores y orquestación con Kubernetes](https://bewiseapps.com/es/software-architecture-wise/cloud-native/containers-and-orchestration): Imágenes, capas, registros y los estándares OCI; por qué hace falta la orquestación; el plano de control de Kubernetes, los nodos, los objetos principales y los bucles de reconciliación; requests, limits y sondas, y cuándo Kubernetes es excesivo.
- [10.3 La aplicación de doce factores y los principios nativos de la nube](https://bewiseapps.com/es/software-architecture-wise/cloud-native/twelve-factor): Los doce factores al completo, con lo que significa cada uno, por qué importa y dónde ha envejecido; los principios que van más allá (desechabilidad, inmutabilidad, observabilidad, seguridad); y una auditoría práctica de un servicio existente con correcciones priorizadas.
- [10.4 Infraestructura como código e infraestructura inmutable](https://bewiseapps.com/es/software-architecture-wise/cloud-native/infrastructure-as-code): Código de infraestructura declarativo e imperativo; Terraform, OpenTofu, CloudFormation, Bicep y Pulumi; estado, bloqueo, deriva, módulos y entornos; infraestructura inmutable; GitOps; política como código; y cómo probarlo todo.
- [10.5 Pipelines de CI/CD y estrategias de despliegue](https://bewiseapps.com/es/software-architecture-wise/cloud-native/ci-cd-and-deployment): Cómo viaja un cambio desde el commit hasta producción: etapas del pipeline, compilar una vez y desplegar muchas, desarrollo basado en trunk, despliegues graduales (rolling), azul-verde (blue-green), canario (canary) y en sombra (shadow), feature flags, migraciones y rollback.
- [10.6 Multirregión, recuperación ante desastres y edge computing](https://bewiseapps.com/es/software-architecture-wise/cloud-native/multi-region-and-edge): Cuándo y cómo operar en varias regiones: latencia, recuperación ante desastres y residencia de datos, las cuatro estrategias de DR con su RTO, RPO y costo, los datos entre regiones, el failover, las células para limitar el radio de impacto, las CDN y las funciones en el borde (edge functions).
- [10.7 Ingeniería de plataformas y plataformas internas para desarrolladores](https://bewiseapps.com/es/software-architecture-wise/cloud-native/platform-engineering): Por qué las organizaciones crean plataformas internas para desarrolladores, los caminos dorados (golden paths) y Backstage, gestionar la plataforma como un producto con autoservicio y guardrails, reducir la carga cognitiva, medir el éxito con DORA y SPACE, y evitar las trampas habituales.
- [10.8 FinOps, arquitectura de costos y dependencia del proveedor (lock-in)](https://bewiseapps.com/es/software-architecture-wise/cloud-native/finops-and-lock-in): Tratar el costo como una cualidad arquitectónica: las fases de FinOps, la economía unitaria, como el costo por pedido, los factores de costo habituales, los descuentos por compromiso de uso y la capacidad spot, el etiquetado, showback y chargeback, y la dependencia del proveedor (lock-in) como compromiso deliberado con una estrategia de salida.

### [Capítulo 11: Evaluación, toma de decisiones y gobernanza](https://bewiseapps.com/es/software-architecture-wise/evaluation-and-governance/)
Avanzado. Cómo se evalúan y gobiernan las arquitecturas: ATAM y revisiones ligeras, funciones de aptitud y arquitectura evolutiva, gobernanza en organizaciones ágiles, Team Topologies, modernización de sistemas heredados, liderazgo, ética y el caso de negocio.

- [11.1 Evaluación de la arquitectura y el ATAM](https://bewiseapps.com/es/software-architecture-wise/evaluation-and-governance/architecture-evaluation): Por qué y cuándo evaluar una arquitectura, cómo funciona paso a paso el ATAM del SEI, qué son los riesgos, los puntos de sensibilidad y los puntos de compromiso, y cómo CBAM añade costos y beneficios.
- [11.2 Revisiones ligeras y risk-storming](https://bewiseapps.com/es/software-architecture-wise/evaluation-and-governance/lightweight-reviews): Por qué las juntas de revisión suelen fracasar y las alternativas ligeras que funcionan: risk-storming, pre-mortems, katas de arquitectura, TARA, revisiones de RFC y listas de comprobación, con un formato de revisión de 90 minutos.
- [11.3 Funciones de aptitud y arquitectura evolutiva](https://bewiseapps.com/es/software-architecture-wise/evaluation-and-governance/fitness-functions): Cómo proteger las características arquitectónicas con comprobaciones automatizadas: qué son las funciones de aptitud, sus categorías, ejemplos para estructura, rendimiento, seguridad, resiliencia y datos, y la arquitectura evolutiva.
- [11.4 Gobernanza de la arquitectura en organizaciones ágiles](https://bewiseapps.com/es/software-architecture-wise/evaluation-and-governance/governance-in-agile): Para qué sirve la gobernanza de la arquitectura y cómo ejercerla sin compuertas lentas: principios, estándares, guardrails, el proceso de consejo (advice process), los foros asesores, los radares tecnológicos, la política como código y la arquitectura empresarial.
- [11.5 Team Topologies y diseño sociotécnico](https://bewiseapps.com/es/software-architecture-wise/evaluation-and-governance/team-topologies): Cómo diseñar los equipos y el software a la vez: los cuatro tipos de equipo, los tres modos de interacción, la carga cognitiva, las API de equipo y los planos de fractura, con un ejemplo práctico de rediseño de los equipos de la plataforma de reparto de comida.
- [11.6 Modernizar sistemas heredados: strangler fig y migración incremental](https://bewiseapps.com/es/software-architecture-wise/evaluation-and-governance/legacy-modernisation): Por qué fracasan las grandes reescrituras y cómo modernizar con seguridad: las siete R, el strangler fig, branch by abstraction, las ejecuciones en paralelo, la captura de datos de cambios, las capas anticorrupción y una migración de datos cuidadosa.
- [11.7 Liderazgo, influencia y toma de decisiones](https://bewiseapps.com/es/software-architecture-wise/evaluation-and-governance/leadership-and-influence): Cómo lideran los arquitectos sin autoridad formal: generar confianza, facilitar decisiones por consentimiento o por consenso, gestionar el conflicto y la política, hablar con los directivos, recorrer el ascensor del arquitecto y hacer crecer a otros arquitectos.
- [11.8 Ética, sostenibilidad y el caso de negocio](https://bewiseapps.com/es/software-architecture-wise/evaluation-and-governance/ethics-and-business-cases): Cómo defender el trabajo de arquitectura en términos de dinero, tiempo y riesgo, con el valor actual neto y el periodo de recuperación calculados paso a paso; y cómo la ética profesional, los daños previsibles y las prácticas de software verde dan forma a un diseño responsable.

### [Capítulo 12: Arquitectura de sistemas con IA](https://bewiseapps.com/es/software-architecture-wise/ai-enabled-systems/)
Avanzado. El aprendizaje automático y los modelos de lenguaje grandes desde el punto de vista de un arquitecto: dónde encajan los modelos, la generación aumentada por recuperación, los agentes y el uso de herramientas, la evaluación, los guardrails, el costo y la latencia, LLMOps y la IA responsable según el Reglamento de IA de la UE (EU AI Act).

- [12.1 Aprendizaje automático y modelos de lenguaje grandes para arquitectos](https://bewiseapps.com/es/software-architecture-wise/ai-enabled-systems/ml-and-llm-basics): Qué hacen realmente el aprendizaje automático y los modelos de lenguaje grandes, desde el entrenamiento y la evaluación hasta los tokens, las ventanas de contexto, el muestreo y los embeddings, y qué implica un componente probabilístico para el sistema que lo rodea.
- [12.2 Dónde encajan los modelos en una arquitectura](https://bewiseapps.com/es/software-architecture-wise/ai-enabled-systems/where-models-fit): Modelos alojados por un proveedor, autoalojados o en el dispositivo; inferencia online y por lotes; gateways de IA, enrutamiento, cascadas y escaleras de alternativas (fallback ladders); humanos en el bucle; cómo elegir un modelo; y una arquitectura de referencia para un asistente de soporte.
- [12.3 Generación aumentada por recuperación y búsqueda vectorial](https://bewiseapps.com/es/software-architecture-wise/ai-enabled-systems/retrieval-augmented-generation): Cómo fundamentar las respuestas del modelo en tus propios datos: ingesta y chunking, embeddings e índices vectoriales, recuperación híbrida y re-ranking, citas, control de acceso, actualización de los datos (freshness), evaluación y modos de fallo.
- [12.4 Agentes, uso de herramientas y orquestación](https://bewiseapps.com/es/software-architecture-wise/ai-enabled-systems/agents-and-tool-use): Cómo llaman los modelos a las herramientas, cómo funciona el bucle del agente, cuándo un flujo de trabajo supera a un agente autónomo, qué estandariza el Model Context Protocol y cómo hacer que los agentes sean fiables con límites, idempotencia, puntos de control (checkpoints) y aprobación.
- [12.5 Evaluación y pruebas de sistemas con IA](https://bewiseapps.com/es/software-architecture-wise/ai-enabled-systems/evaluating-ai-systems): Cómo probar componentes cuyas salidas varían: conjuntos dorados (golden sets), métodos de puntuación, LLM como juez (LLM-as-judge) y sus sesgos, evaluación offline y online, evaluaciones de regresión en CI, monitorización en producción, red teaming y la confianza en las cifras.
- [12.6 Guardrails, seguridad (safety) e inyección de prompts](https://bewiseapps.com/es/software-architecture-wise/ai-enabled-systems/guardrails-and-safety): Por qué un modelo de lenguaje es un componente no confiable: la inyección de prompts directa e indirecta, los jailbreaks, el OWASP Top 10 for LLM Applications, la tríada letal (lethal trifecta) y las defensas por capas que se mantienen aunque el modelo sea manipulado.
- [12.7 Costo, latencia y LLMOps](https://bewiseapps.com/es/software-architecture-wise/ai-enabled-systems/cost-latency-and-llmops): La economía y la operación de las llamadas a modelos: tokens de entrada y de salida, tiempo hasta el primer token y streaming, caché de prompts y caché semántica, procesamiento por lotes, cascadas, límites de tasa y escaleras de alternativas, versionado, trazado y monitorización de costos.
- [12.8 Gobernanza de datos, IA responsable y el Reglamento de IA de la UE](https://bewiseapps.com/es/software-architecture-wise/ai-enabled-systems/responsible-ai): Convertir los principios de IA responsable en arquitectura: procedencia de los datos y datos personales en prompts y logs, sesgo y equidad, transparencia y model cards, supervisión humana, el Reglamento de IA de la UE (EU AI Act) en su versión modificada de 2026, el NIST AI RMF e ISO/IEC 42001.

## Otras páginas

- [Glosario](https://bewiseapps.com/es/software-architecture-wise/glossary)
- [Cómo funcionan el curso, las pruebas y el certificado](https://bewiseapps.com/es/software-architecture-wise/how-it-works)
- [Una ruta para principiantes](https://bewiseapps.com/es/software-architecture-wise/beginners-path): un recorrido sugerido por el curso en seis etapas para quienes se inician en el software, con un método para las secciones más difíciles
- [Una ruta para estudiantes con experiencia](https://bewiseapps.com/es/software-architecture-wise/experienced-route): los capítulos en el mismo orden, del 0 al 12, para quienes ya trabajan con software, con indicaciones sobre qué pueden leer por encima; para el certificado hay que aprobar igualmente todas las pruebas de capítulo
- [Comprobar un certificado](https://bewiseapps.com/es/software-architecture-wise/verify)