Visión general de la arquitectura

Resumen de una arquitectura multi-repositorio organizada en capas para separar responsabilidades, facilitar evolución y escalar con mayor control.

Objetivo de esta arquitectura

La arquitectura propuesta busca resolver un problema común en sistemas que crecen:

demasiadas responsabilidades mezcladas
dificultad para desplegar sin riesgo
integraciones externas contaminando el dominio
complejidad creciente en frontend y backend
acoplamiento entre equipos y componentes

Para responder a eso, se organiza el sistema en capas y servicios con límites más claros.

La idea no es añadir complejidad porque sí, sino distribuir la complejidad en lugares donde sea más manejable.

Las 7 capas

1. Presentation

Aquí vive la interfaz de usuario. Renderiza pantallas, maneja estado, valida formularios del lado del cliente y consume APIs.

2. API Gateway

Es la puerta de entrada principal. Aplica autenticación, routing, rate limiting, logging y otras capacidades transversales.

3. BFF

Agrega y transforma datos para la UI. Reduce la complejidad del frontend y evita que el cliente conozca demasiados detalles internos.

4. Microservicios

Contienen la lógica de negocio organizada por dominios o bounded contexts. Aquí viven las reglas, los casos de uso, los eventos de dominio y la persistencia.

5. Event Bus

Permite comunicación asíncrona entre servicios mediante eventos. Favorece el desacoplamiento temporal y la construcción de procesos distribuidos.

6. ACL

Protege el dominio frente a sistemas externos o legacy. Traduce modelos y encapsula adaptadores para no contaminar el core del negocio.

7. Data / External Systems

Incluye bases de datos, caché, sistemas heredados y proveedores de terceros.

¿Por qué separar en capas?

Separar en capas permite:

Claridad de responsabilidades

Cada parte del sistema tiene un foco más específico.

Menor acoplamiento

El frontend no necesita conocer detalles internos de cada microservicio. Los servicios de dominio no deberían depender directamente del modelo de un ERP legado.

Escalabilidad técnica

Puedes escalar componentes distintos según sus necesidades reales.

Escalabilidad organizacional

Los equipos pueden trabajar sobre áreas más claras, con ownership definido.

Evolución controlada

Cambiar una pieza afecta menos a las demás si los límites están bien definidos.

Comunicación entre capas

En esta arquitectura conviven dos grandes formas de comunicación:

Comunicación síncrona

Se usa cuando una capa necesita una respuesta inmediata. Por ejemplo:

frontend → gateway
gateway → BFF
BFF → microservicios

Normalmente ocurre por HTTP o GraphQL/REST.

Comunicación asíncrona

Se usa cuando un servicio publica un hecho y otros reaccionan sin necesidad de responder de forma inmediata.

Por ejemplo:

ms-orders publica OrderPlaced
inventory reacciona
notifications reacciona
analytics reacciona

Ambas conviven porque resuelven necesidades distintas.

Multi-repo: por qué separar repositorios

La arquitectura está planteada en múltiples repositorios, uno por capa o por servicio principal.

Esto permite:

independencia de despliegue
ownership más claro
menor tamaño por repositorio
mejor aislamiento por dominio

Pero también exige:

estándares compartidos
acuerdos de versionado
disciplina con contratos
control del shared kernel

El multi-repo no es automáticamente mejor; es una decisión que debe acompañar una necesidad real de separación.

Principios que sostienen la arquitectura

Separación de responsabilidades

Cada capa resuelve un problema diferente.

Dominio protegido

Las reglas de negocio deben vivir en el lugar correcto y no contaminarse con modelos externos.

Contratos explícitos

La comunicación entre partes del sistema debe estar definida y ser entendible.

Evolución independiente

Cada parte debe poder cambiar con la menor fricción posible.

Observabilidad y seguridad desde el diseño

No deben añadirse al final como un parche.

Qué no significa esta arquitectura

Es importante evitar algunas malas interpretaciones.

No significa que todo deba ser un microservicio

Hay que separar cuando existe un límite claro y una necesidad real.

No significa que más capas siempre sea mejor

Cada capa debe justificar el valor que aporta.

No significa que la complejidad desaparezca

La complejidad no desaparece; se organiza mejor.

No significa que el shared kernel pueda crecer sin control

Compartir demasiado puede recrear acoplamientos fuertes.

Cómo recorrer esta sección

Resumen

Esta arquitectura organiza el sistema en capas con responsabilidades diferenciadas para favorecer claridad, escalabilidad y evolución controlada. No busca imponer complejidad, sino ubicar cada tipo de complejidad en el lugar donde pueda manejarse mejor.