Arquitectura de software
Conjunto de decisiones de diseño importantes para organizar el sistema y promover atributos de calidad deseados (Ralph Johnson: “lo importante, sea lo que sea”).
Principios transversales (agregados de 5+ fuentes)
- Domain centric. Clean, Hexagonal, Onion son variantes del mismo principio — dominio al centro, infraestructura afuera, regla de dependencia hacia adentro.
- Complejidad esencial vs accidental. Toda arquitectura busca minimizar la segunda.
- Cohesión → SRP. La cohesión es la causa del Single Responsibility, no su consecuencia.
- Puertos y adaptadores. Interfaces pertenecen al dominio, implementaciones a infraestructura.
- Inversión de dependencias a nivel arquitectónico.
- Usa solo las capas que necesitas, no más — “lasagna architecture” es antipatrón.
Las escuelas (mapa)
| Escuela | Clave distintiva |
|---|---|
| MVC (1979) | Model-View-Controller, separación UI/business |
| MVP (1996) | Vista pasiva, presenter thin |
| MVVM (2005) | Data binding, viewModel corresponde 1:1 con view |
| EBI (1992) | Entity-Boundary-Interactor (Ivar Jacobson, backend) |
| DDD (1990s) | Ubiquitous language, bounded contexts, agregados |
| Hexagonal (2005) | Ports & adapters, primary vs secondary |
| Onion (2008) | Dominio al centro + capas concéntricas |
| Clean (2012) | Síntesis de Onion + Hexagonal + DDD por Uncle Bob |
| CQRS | Separar commands de queries |
| Event-Driven | Eventos como primer ciudadano |
⚠ Tensión / contradicción documentada
Jeremy Miller (en swe-management-career-agregada) critica Clean y Onion directamente:
“Apueste aún, hágalo sin introducir complejidad innecesaria o ceremonia de código a través de arquitecturas prescriptivas bien intencionadas como ‘Onion’ o ‘Clean’ que deliberadamente intentan obligar a los desarrolladores a escribir código ‘de la manera correcta’.”
Corolario de Miller: “Cuidado con SOLID, a veces es difícil satisfacer, entender y aplicar.”
Resolución parcial del wiki: la escuela importa menos que la intención arquitectónica. Usar la ceremonia solo donde paga — ver también “duplicar puede ser mejor que sobre-ingeniería” (2024-12-26-swe-principios-brian-enzo).
Contradicción con swe-architecture-agregada y mainstream Clean/Hexagonal
Estado: ambas vigentes — úsalas como guardrails mutuos.
Refuerzo externo — 5 voces independientes (oct 2024, omnivore-arquitectura-simplicidad-agregada)
5 autores externos convergen con Miller desde ángulos distintos:
- Attila Vágó (KISS) — “KISS subsume DRY, YAGNI, SOLID. La abstracción excesiva añade carga cognitiva extra.”
- Nicholas Ocket (Lean Architecture) — “It is high time to kill Clean.” Las reglas Clean/Hexagonal se enseñan sin entender el problema que resuelven; “people implementan arquitectura por la arquitectura misma”. Convergencia DIRECTA con Miller.
- Crank Lee (Stop Fancy Tricks) — “The higher the level of programmer, the smaller the proportion of technical knowledge in the skill tree.” Los seniors miden architectural ability + business understanding, no tricks.
- Victoria Corindi (Enemy of Good) — cita Steve Jobs “simple is harder than complex”. 5 beneficios de soluciones simples: Clarity · Efficiency · Usability · Adaptability · Reliability.
- Amit Verma (18 patterns) — cita Dave Thomas: “Big design up front is dumb, but doing no design up front is even dumber.”
Conclusión consolidada: la tesis “arquitectura como tool, no como ritual” tiene 6 voces independientes (Miller + estos 5). La regla práctica del wiki (“usá la arquitectura más simple que soporte el cambio previsible”) queda validada.
7ª voz (mayo 2026): Dan North (vía swe-solid-cupid-meta-estudio) — “SOLID es heurística, no regla”. North formaliza académicamente lo que Miller y Ocket dicen desde la práctica. Propone cupid como reframe explícito: pasar de principios (cumplir/no) a propiedades (centro hacia el cual moverse).
8ª voz (mayo 2026) — convergencia de tres voces editoriales en inbox-2026-05-system-design-arquitectura-agregada:
- AlgoMaster (2026-05-12) Monolith vs Microservices vs Modular Monoliths — regla operativa con números: equipo <10 → monolito; 10-50 con dominios claros → monolito modular; >50 con deployment independiente crítico → microservicios. “Siempre empieza más simple de lo que crees necesitar.” Strangler Fig = ruta de migración correcta.
- bytebytego EP210 Monolith vs Microservices vs Serverless — la decisión arquitectónica más frecuente del backend. Convergente con AlgoMaster.
- Refactoring (Luca Rossi) Compounding Software Factory — código modular = capital que trabaja con el tiempo; deuda técnica interrumpe el compounding y deprecia el capital acumulado.
La tesis “arquitectura como tool, no como ritual” tiene ahora 8 voces independientes y, por primera vez, umbral cuantitativo observable (10-50 ingenieros) para resolver el dilema monolito/microservicios. Esto cierra parcialmente la pregunta abierta “¿la crítica de Miller escala a proyectos de 20 devs?” — la respuesta consolidada es: monolito modular es la respuesta operativa para ese rango.
CUPID como lente ortogonal
Las escuelas (Clean/Hexagonal/Onion/DDD/MVVM) responden “¿cómo organizo el código?“. CUPID responde “¿cómo se siente trabajar con este código?“. Son ortogonales — un sistema Clean puede ser CUPID-compliant o no.
| Pregunta | Marco que responde |
|---|---|
| ¿Cómo separo concerns? | Clean / Hexagonal / Onion / DDD |
| ¿Cómo se siente este código a quien lo usa? | cupid |
| ¿Cómo evito antipatrones? | stupid |
| ¿Qué reglas durante el desarrollo? | solid (como heurística) |
Domain-based (la “D” de CUPID) conecta directamente con DDD: cuando los límites del módulo coinciden con los límites del dominio, la implementación se vuelve sencilla.
Lean Architecture — proceso de 5 pasos (Ocket)
Alternativa explícita a Clean/Hexagonal/Onion como “reglas”:
- Análisis del problema y stakeholders.
- Análisis del use case actual — input/output/transformaciones.
- Modelado — representaciones buenas del problema.
- Implementación + tests de las piezas.
- Gestión de dependencias — qué impacta a qué cuando cambia.
Pregunta-guía permanente:
“How much design do we need to implement right now to keep the codebase maintainable?”
Regla práctica extraíble
Usa la arquitectura más simple que soporte el cambio previsible. Ni “lasagna” ni todo en un archivo.
Ideas clave por DDD
- Ubiquitous language — alinear vocabulario negocio↔técnica.
- Bounded contexts — subsistemas con acoplamiento fuerte interno, débil entre.
- Anti-Corruption Layer — middleware que aísla (ideal para legacy).
- Shared Kernel — pequeño, cuidado al modificar.
- Generic subdomain — lo reutilizable entre apps.
Fuentes
- swe-architecture-agregada — 5 notas agregadas (420+ líneas de material).
- swe-design-patterns-gof-agregada — los patterns son vocabulario compartido + CQS + Parameter Object.
- swe-management-career-agregada — contradicción Jeremy Miller.
- swe-solid-cupid-meta-estudio — Modern SOLID 2021 + Dan North heurística + CUPID alternativa formal.
- swe-flutter-community-conferences-agregada — Flutter Layered Architecture (VGV) como instancia concreta de la regla domain-centric.
- omnivore-arquitectura-simplicidad-agregada — 5 voces externas que convergen con Miller (Vágó, Ocket, Crank Lee, Corindi, Verma).
- 2024-12-26-swe-principios-brian-enzo — principios aplicados a Flutter/Dart.
- post-solid-stupid-2025-01-24 — SOLID/STUPID como frame ortogonal.
- bc-4-claves-romper-seniority — “arquitectura + patrones como señal de madurez”.
- bc-5-pr-11000-lineas — arquitectura aplicada a PR real.
- inbox-2026-05-system-design-arquitectura-agregada ⭐ — 8ª voz: AlgoMaster (umbral cuantitativo) + ByteByteGo (decisión arquitectónica recurrente) + Refactoring (compounding factory).
- ai-engineer-agentes-mcp-evals-agregada ⭐ — 9ª voz: aplica los mismos principios al dominio agentic. Durabilidad como atributo de calidad de primer nivel (Temporal, Vercel DevKit, Trigger.dev snapshots con Firecracker microVMs); API Gateway pattern aplicado a MCP (Karan Sampath, Anthropic — Gateways are All You Need); microservicios prematuros = “sobre-segmentación de agentes” (Sandipan Bhaumik — From Chaos to Choreography). Confirma que el debate “orquestador central vs coreografía libre” es el mismo debate clásico en ámbito nuevo.
Conexiones
- solid · stupid · singleton · cupid — vocabulario interno.
- seniority-developer — criterio arquitectónico = meta-skill del senior.
- vibe-coding — tensión nueva: si la IA escribe código, ¿la arquitectura se democratiza o se degrada?
Preguntas abiertas
- ¿Cómo enseñar criterio arquitectónico? Ninguna fuente lo responde.
- ¿Hay métrica objetiva de “sobre-ingeniería”? Nadie mide.
- ¿La crítica de Miller escala a proyectos de 20 devs? (Sospecha: no — la ceremonia evita chaos a escala).