Proyecto American Flights: arquitectura 3 capas (ib-s/ib-p/ib-e) explicada

Uno de los conceptos que más cuesta interiorizar al empezar con MuleSoft no es técnico, es de diseño: por qué separar la lógica en tres capas en vez de meterla toda en una sola API. En el proyecto American Flights, que usamos como hilo conductor en el curso de Developer, esto se ve con nombres concretos: ib-s, ib-p e ib-e.

Las tres capas, sin jerga

API-led connectivity es el patrón que MuleSoft promueve para estructurar integraciones. La idea central: cada capa tiene una única responsabilidad y no sabe (ni le importa) cómo están construidas las demás.

• Capa de Sistema (ib-s): habla directamente con el sistema de origen (una base de datos, un ERP, una API de un tercero). Su trabajo es exponer esos datos de forma consistente, sin lógica de negocio. Si el sistema de origen cambia por dentro, solo esta capa se entera.
• Capa de Proceso (ib-p): combina y transforma datos de una o varias capas de sistema para resolver un caso de negocio concreto. Aquí vive la lógica de «cómo se cruza esto con aquello».
• Capa de Experiencia (ib-e): adapta los datos al consumidor final (una app móvil, un portal web, un partner). Formatea la respuesta exactamente como ese canal la necesita.

Por qué separar esto en vez de hacer una API monolítica

El error de principiante es preguntarse «¿por qué no hago una sola API que haga todo?». La respuesta se ve cuando algo cambia:

• Si el sistema de vuelos cambia de proveedor de base de datos, solo tocas ib-s. ib-p y ib-e no se enteran, porque consumen un contrato estable, no la base de datos directamente.
• Si mañana necesitas exponer los mismos datos de vuelos a una nueva app con un formato de respuesta distinto, añades una nueva ib-e sin tocar la lógica de negocio de ib-p.
• Si el proceso de negocio cambia (por ejemplo, ahora hay que validar disponibilidad cruzando dos sistemas en vez de uno), eso vive en ib-p, aislado de cómo se expone después.

Sin esta separación, cualquier cambio en el sistema de origen se propaga en cascada por toda la API, y cualquier cambio de formato para un consumidor obliga a tocar lógica de negocio que no tiene nada que ver.

Cómo se ve en el proyecto American Flights

En el proyecto que construimos paso a paso en el curso:

1. ib-s-flights expone los datos crudos de vuelos desde la base de datos, con operaciones simples de lectura (y solo lectura donde corresponde — ver también nuestra guía de POST sin INSERT para el patrón inverso).
2. ib-p-flights combina la información de vuelos con la de disponibilidad y aplica las reglas de negocio (por ejemplo, qué vuelos mostrar según origen/destino).
3. ib-e-flights expone el endpoint final que consume la app, con el formato de respuesta que el frontend espera, incluyendo paginación y manejo de errores amigable para el cliente.

El error típico al aplicar esto por primera vez

Cuando alguien aplica API-led connectivity por primera vez, suele cometer uno de estos dos errores:

• Poner lógica de negocio en la capa de sistema («ya que estoy aquí, filtro estos resultados») — rompe la reutilización de esa capa de sistema por otros procesos.
• Hacer que la capa de experiencia llame directamente al sistema de origen, saltándose proceso — funciona a corto plazo, pero recrea el acoplamiento que la arquitectura intentaba evitar.

La regla práctica: si te preguntas «¿esta lógica depende de un caso de uso específico o es un dato reutilizable?», esa pregunta te dice en qué capa va.

Por qué esto importa para tu certificación

Los escenarios de examen del MCD-L1 (y más aún del nivel Architect) evalúan exactamente esta capacidad de decisión: dado un caso, ¿en qué capa colocarías esta lógica? No es teoría abstracta — es la habilidad que separa a quien memorizó definiciones de quien construyó algo real.

En el curso de MuleSoft Developer trabajamos las tres capas del proyecto American Flights de principio a fin, así que cuando llegues a estos escenarios en el examen, ya los habrás resuelto en código, no solo en teoría.