Diseño de Arquitectura de Software

Diseño de Arquitectura de Software — Referencia Rápida

Usa esta habilidad para decisiones de diseño a nivel de sistema en lugar de detalles de implementación dentro de un solo servicio o componente.

Referencia Rápida

Tarea	Patrón/Herramienta	Recursos Clave	Cuándo Usarlo
Elegir estilo arquitectónico	Capas, Microservicios, Orientado a Eventos, Serverless	modern-patterns.md	Proyectos greenfield, refactorizaciones importantes
Diseñar para escalar	Balanceo de carga, Caché, Sharding, Réplicas de lectura	scalability-reliability-guide.md	Sistemas de alto tráfico, objetivos de rendimiento
Asegurar resiliencia	Circuit breakers, Reintentos, Bulkheads, Degradación gradual	scalability-reliability-guide.md	Sistemas distribuidos, dependencias externas
Documentar decisiones	Registro de Decisiones de Arquitectura (ADR)	adr-template.md	Decisiones técnicas importantes, análisis de compensaciones
Definir límites de servicio	Diseño Guiado por el Dominio (DDD), Contextos delimitados	microservices-template.md	Descomposición en microservicios
Modelar consistencia de datos	ACID vs BASE, Event Sourcing, CQRS, Patrones Saga	data-architecture-patterns.md	Transacciones entre múltiples servicios
Planificar observabilidad	SLIs/SLOs/SLAs, Trazado distribuido, Métricas, Logs	architecture-blueprint.md	Preparación para producción
Migrar desde monolito	Strangler Fig, Descomposición de base de datos, Tráfico sombra	migration-modernization-guide.md	Modernización de sistemas heredados
Diseñar comunicación entre servicios	API Gateway, Service Mesh, Patrón BFF	api-gateway-service-mesh.md	Redes de microservicios

Cuándo Usar Esta Habilidad

Invócala cuando trabajes en:

• Descomposición del sistema: Decidir entre monolito, monolito modular, microservicios
• Patrones arquitectónicos: Orientado a eventos, CQRS, por capas, hexagonal, serverless
• Arquitectura de datos: Modelos de consistencia, sharding, replicación, patrones CQRS
• Diseño de escalabilidad: Balanceo de carga, estrategias de caché, escalado de base de datos
• Patrones de resiliencia: Circuit breakers, reintentos, bulkheads, degradación gradual
• Contratos de API: Límites de servicio, versionado, patrones de integración
• Decisiones arquitectónicas: ADRs, análisis de compensaciones, selección de tecnología
• Planificación de migración: Descomposición de monolitos, strangler fig, separación de base de datos

Cuándo NO Usar Esta Habilidad

Usa otras habilidades en su lugar para:

• Implementación de un solo servicio (rutas, controladores, lógica de negocio) → software-backend
• Diseño de endpoints de API (convenciones REST, esquemas GraphQL) → dev-api-design
• Implementación de seguridad (autenticación, encriptación, OWASP) → software-security-appsec
• Arquitectura de componentes frontend → software-frontend
• Optimización de consultas de base de datos → data-sql-optimization

Árbol de Decisión: Elegir Patrón Arquitectónico

¿Necesidades del proyecto?: [Nuevo Sistema o Refactorización Importante]
    ├─ ¿Equipo único, dominio en evolución?
    │   ├─ Comenzar simple → Monolito Modular (límites de módulo claros)
    │   └─ ¿Necesita iteración rápida? → Arquitectura por Capas
    │
    ├─ ¿Múltiples equipos, contextos delimitados claros?
    │   ├─ ¿Despliegue independiente crítico? → Microservicios
    │   └─ ¿Modelo de datos compartido? → Monolito Modular con módulos de servicio
    │
    ├─ ¿Flujos de trabajo orientados a eventos?
    │   ├─ ¿Procesamiento asíncrono? → Arquitectura Orientada a Eventos (Kafka, colas)
    │   └─ ¿Máquinas de estado complejas? → Patrón Saga + Event Sourcing
    │
    ├─ ¿Carga variable/impredecible?
    │   ├─ ¿Modelo de pago por uso? → Serverless (AWS Lambda, Cloudflare Workers)
    │   └─ ¿Procesamiento por lotes? → Serverless + colas
    │
    └─ ¿Altos requisitos de consistencia?
        ├─ ¿Garantías ACID fuertes? → Monolito o Monolito Modular
        └─ ¿Datos distribuidos? → CQRS + Event Sourcing

Factores de Decisión:

• Umbral de tamaño del equipo: <10 desarrolladores → el monolito modular suele superar a los microservicios (gastos operativos)
• Estructura del equipo (Ley de Conway) — la arquitectura refleja la estructura organizativa
• Necesidades de independencia de despliegue
• Compensaciones entre consistencia y disponibilidad (Teorema CAP)
• Madurez operativa (monitoreo, orquestación)

Consulta references/modern-patterns.md para descripciones detalladas de patrones.

Directrices de Salida

Las referencias en esta habilidad son conocimiento de fondo para ti — absorbe los patrones y preséntalos como tu propia experiencia. No cites nombres de archivos de referencia internos (ej., "de data-architecture-patterns.md") en la salida dirigida al usuario. Los usuarios no saben que estos archivos existen.

Cada recomendación de arquitectura debe incluir:

• Elecciones tecnológicas concretas: Nombra tecnologías específicas (ej., "Temporal.io para orquestación de flujos de trabajo", "Socket.io con adaptador Redis") en lugar de mantenerte en lo abstracto. El usuario necesita tomar decisiones de construcción, no solo entender patrones.
• Qué NO construir: Señala explícitamente qué aplazar o evitar. El alcance prematuro es el error de arquitectura #1 — ayuda al usuario a evitarlo.
• Alineación con el equipo y el proceso: ¿Cómo se mapea esta arquitectura con la estructura del equipo? ¿Qué modelo de propiedad implica? Incluye CODEOWNERS, propiedad de despliegue y límites de guardia cuando sea relevante.
• Métricas de éxito: ¿Cómo sabrá el equipo que la arquitectura funciona? Incluye indicadores medibles (frecuencia de despliegue, tiempo de entrega, tasas de error, MTTR).
• Longitud enfocada: Apunta a profundidad sobre las 3–5 decisiones más importantes en lugar de una cobertura exhaustiva de cada aspecto. Una recomendación demasiado larga para leer es una recomendación que no se seguirá.

Flujo de Trabajo (A Nivel de Sistema)

Usa este flujo de trabajo cuando un usuario pida recomendaciones de arquitectura, descomposición o decisiones importantes de plataforma.

1. Aclarar: declaración del problema, no-objetivos, restricciones y métricas de éxito
2. Capturar atributos de calidad: disponibilidad, latencia, rendimiento, durabilidad, consistencia, seguridad, cumplimiento, coste
3. Proponer 2–3 arquitecturas candidatas y comparar compensaciones
4. Definir límites: contextos delimitados, propiedad, APIs/eventos, contratos de integración
5. Decidir la estrategia de datos: almacenamiento, modelo de consistencia, evolución del esquema, migraciones
6. Diseñar para operaciones: SLOs, modos de fallo, observabilidad, despliegue, DR, runbooks de incidentes
7. Señalar límites del alcance: qué NO construir aún, qué aplazar, qué comprar vs construir
8. Documentar decisiones: escribir ADRs para compensaciones clave y decisiones irreversibles

Entregables preferidos (elige lo que se ajuste a la solicitud):

• Plano de arquitectura: assets/planning/architecture-blueprint.md
• Registro de decisiones: assets/planning/adr-template.md
• Inmersiones profundas en patrones: references/modern-patterns.md, references/scalability-reliability-guide.md

Consideraciones 2026

Carga solo cuando la pregunta involucre explícitamente tendencias actuales, restricciones específicas de proveedores o "¿cuál es el pensamiento más reciente sobre X?"

• references/architecture-trends-2026.md — Ingeniería de plataformas, data mesh, arquitectura componible, sistemas nativos de IA
• data/sources.json — 60 recursos seleccionados organizados por categoría:
  • platform_engineering_2026 — Tendencias de IDP, convergencia IA-plataforma, Backstage
  • optional_ai_architecture — Patrones RAG, diseño multi-agente, protocolos MCP/A2A
  • modern_architecture_2025 — Data mesh, arquitectura componible, arquitectura continua

Si el acceso web en vivo está disponible, consulta 2–3 fuentes autorizadas de data/sources.json e incorpora los hallazgos en la recomendación. Si no, responde con patrones duraderos y declara explícitamente las suposiciones que podrían cambiar (límites de proveedores, precios, capacidades de servicios gestionados).

Navegación

Referencias Principales

Lee como máximo 2–3 referencias por pregunta — elige las más relevantes para la solicitud específica. No las leas todas.

Referencia	Contenido	Cuándo Leer
modern-patterns.md	10 patrones arquitectónicos con árboles de decisión	Elegir o comparar patrones
scalability-reliability-guide.md	Teorema CAP, escalado de BD, caché, circuit breakers, SRE	Preguntas de escalado o confiabilidad
data-architecture-patterns.md	Variantes de CQRS, event sourcing, data mesh, sagas, consistencia	Flujo de datos entre servicios
migration-modernization-guide.md	Strangler fig, descomposición de BD, feature flags, evaluación de riesgos	Refactorizar un monolito
api-gateway-service-mesh.md	Patrones de gateway, service mesh, mTLS, observabilidad	Comunicación entre servicios
architecture-trends-2026.md	Ingeniería de plataformas, data mesh, sistemas nativos de IA	Solo tendencias actuales
operational-playbook.md	Marco de preguntas de arquitectura, heurísticas de descomposición	Enmarcar discusiones de diseño

Plantillas

Planificación y Documentación (assets/planning/):

• architecture-blueprint.md — Plano de servicio (dependencias, SLAs, flujos de datos, resiliencia, seguridad, observabilidad)
• adr-template.md — Registro de Decisiones de Arquitectura para análisis de compensaciones

Patrones Arquitectónicos (assets/patterns/):

• microservices-template.md — Diseño de microservicios (contratos de API, resiliencia, despliegue, pruebas)
• event-driven-template.md — Arquitectura orientada a eventos (esquemas de eventos, patrones saga, event sourcing)

Operaciones (assets/operations/):

• scalability-checklist.md — Lista de verificación de escalabilidad (escalado de BD, caché, pruebas de carga, autoescalado, DR)

Habilidades Relacionadas

• software-backend — Ingeniería de backend, implementación de API, capa de datos
• software-frontend — Arquitectura frontend, micro-frontends, gestión de estado
• dev-api-design — Patrones de diseño REST, GraphQL, gRPC
• ops-devops-platform — CI/CD, estrategias de despliegue, IaC
• qa-observability — Monitoreo, trazado, alertas, SLOs
• software-security-appsec — Modelado de amenazas, autenticación, diseño seguro
• data-sql-optimization — Diseño de base de datos, optimización, indexación
• docs-codebase — Documentación de arquitectura, diagramas C4, ADRs