Fundamentos · 02

Arquitectura y Diseño: el marco que hace posible la IA

Ningún workflow de IA sustituye una arquitectura sólida. La arquitectura define los límites del sistema y, por tanto, los límites en los que los agentes pueden operar con seguridad. Elegir bien es el primer acto de diseño.

Panorama

Estilos arquitectónicos relevantes

Monolito modular

modular-monolith

Un único deployable con módulos internos acotados por dominio.

Usar cuando

Equipo pequeño o mediano
Dominio aún en exploración
Se busca simplicidad operacional

Evitar cuando

Necesidad real de escalado independiente
Equipos numerosos que chocan en el mismo código

Trade-offs

Simplicidad operacional ↔ acoplamiento por cercanía
Refactor barato ↔ riesgo de erosión de módulos

IAAgentes operan sobre todo el repositorio con contexto completo; ideal para specs que cubren el dominio end-to-end.

SpecLas specs pueden razonar en términos de módulos lógicos sin preocuparse aún por contratos de red.

Microservicios

microservices

Servicios independientes, desplegables por separado, comunicados por red.

Usar cuando

Equipos independientes con ciclos distintos
Necesidad de escalar partes específicas
Tolerancia a fallos por dominio

Evitar cuando

Equipo pequeño sin cultura de ops
Dominio inmaduro o cambiante
Latencias críticas no tolerables

Trade-offs

Escalado independiente ↔ complejidad operacional
Aislamiento ↔ consistencia distribuida difícil

IAAgentes trabajan por servicio con specs acotadas; MCP expone contratos compartidos y eventos.

SpecLas specs deben incluir contratos (OpenAPI/AsyncAPI), versionado y compatibilidad.

Hexagonal (Ports & Adapters)

hexagonal

El dominio está en el centro y los adaptadores traducen al exterior.

Usar cuando

Se espera cambiar infraestructura
Se priorizan pruebas de dominio puras
Se quiere aislar reglas de negocio

Evitar cuando

CRUD trivial sin reglas complejas

Trade-offs

Testabilidad alta ↔ más abstracciones
Portabilidad ↔ curva de aprendizaje

IAAgentes distinguen claramente dominio (lógica) de adaptadores (IO), lo que reduce errores.

SpecLas specs separan "qué hace el dominio" de "cómo se conecta al mundo".

Clean Architecture

clean-architecture

Capas concéntricas con dependencias siempre hacia el dominio.

Usar cuando

Sistemas longevos con reglas complejas
Equipos distribuidos que necesitan contratos claros

Evitar cuando

Prototipos rápidos o scripts

Trade-offs

Mantenibilidad ↔ overhead inicial
Separación clara ↔ más indirecciones

IAPermite specs por capa (casos de uso, entidades, interfaces) y agentes especializados por capa.

SpecSe escriben specs a nivel de "use case" que son directamente testeables.

Event-Driven Architecture

event-driven

El sistema reacciona a eventos; la verdad está en el log.

Usar cuando

Flujos asíncronos y desacoplados
Integraciones entre dominios
Necesidad de auditabilidad

Evitar cuando

Flujos síncronos simples

Trade-offs

Desacoplo ↔ eventual consistency
Escalabilidad ↔ trazabilidad más compleja

IAAgentes pueden suscribirse a eventos y actuar como consumidores inteligentes (ej. triage, análisis).

SpecLas specs describen eventos, productores, consumidores y garantías (at-least-once, idempotencia).

Serverless / Functions

serverless

Ejecución por demanda sin gestión explícita de servidores.

Usar cuando

Carga irregular
Time-to-market agresivo
Eventos puntuales (webhooks, colas)

Evitar cuando

Procesos largos o con estado en memoria
Latencias frías inaceptables

Trade-offs

Coste por uso ↔ lock-in de proveedor
Escalado automático ↔ límites de ejecución

IAIdeal para exponer herramientas a agentes: cada función es una "tool" con contrato claro.

SpecLas specs definen triggers, contratos I/O y política de errores por función.

Decisión

Cómo elegir el estilo correcto

No existe una arquitectura "por defecto correcta". La elección depende del dominio, del tamaño del equipo, del ciclo de cambio, del riesgo y del presupuesto operacional. La regla general es empezar simple y migrar cuando el dolor sea real, no teórico.

Un buen arquitecto verbaliza el trade-off: "si elegimos microservicios ahora, gastamos coordinación a cambio de escalabilidad que todavía no necesitamos". Esa honestidad técnica es lo que convierte decisiones en ADRs útiles.

Tamaño de equipo

¿Cuántos pods necesitan trabajar en paralelo sin pisarse?

Cadencia de cambio

¿Qué partes cambian varias veces al día y cuáles rara vez?

Coste operacional

¿Tienes cultura de ops para sostener la complejidad elegida?

Riesgo de dominio

¿Es un dominio maduro o todavía estás descubriéndolo?

Arquitectura + IA

El papel de la IA dentro de cada estilo

La IA no cambia los fundamentos: los amplifica. En un monolito modular, un agente puede razonar con todo el contexto y refactorizar con seguridad si hay pruebas. En microservicios, los agentes se vuelven locales a cada servicio y se apoyan en MCP para compartir contratos y documentación viva.

En event-driven, los agentes pueden consumir eventos como "señales" para triage, análisis o propuestas de corrección automatizadas. En hexagonal y clean architecture, la separación entre dominio e infraestructura reduce drásticamente los errores de la IA: el modelo no confunde "qué" con "cómo".

La conclusión práctica: cuanto mejor está diseñada la arquitectura, más útil es la IA. Los proyectos con acoplamientos difusos son los más peligrosos para introducir agentes.