Enfoque de Componentes en Arquitectura de Software

Arquitectura basada en componentes: De monolito a sistemas escalables

La arquitectura basada en componentes trata los directorios como bloques de construcción en un diagrama y las dependencias como líneas de conexión. Cada componente es un directorio de código compilado en una biblioteca. Las dependencias se gestionan con la herramienta de compilación: por ejemplo, crm/core incorpora crm/api y payments/api para integrarse con una pasarela de pagos.

Esto genera una anidación natural, similar a un sistema de archivos, garantizando interoperabilidad fluida. El enfoque funciona con cualquier herramienta de compilación moderna y lenguaje, escalando desde monolitos hasta microservicios.

API y SPI para abstracción de datos

Separa la lógica de negocio principal de la infraestructura con el patrón API-SPI. La API es el contrato que expone tu app (como una interfaz de CRM). El SPI es el contrato para proveedores externos (Postgres para almacenamiento, TigerBeetle para pagos).

Beneficios clave:

• La lógica principal permanece independiente de bases de datos o servicios específicos.
• Cambia implementaciones sin recompilar el núcleo.
• Soporta múltiples proveedores en un solo proceso de arranque.

El diagrama ubica core entre api y spi, con componentes de infraestructura que implementan el SPI.

Arranque para ensamblaje de la app

Crea un componente de arranque como dependencia plug-and-play. Conecta implementaciones SPI a las APIs en el contexto de la app. Los frameworks modernos resuelven dependencias automáticamente; en lenguajes puros, usa la configuración de compilación.

Ejemplo: Un arranque de CRM conecta crm/core y payments/core mediante un contexto compartido. Esto simplifica el despliegue: solo agrega la dependencia y listo.

Evolución hacia microservicios

Para escalado independiente, descompón el monolito:

• Extrae apps independientes para CRM y pagos.
• Agrega un rest-client en CRM que implementa la API de Pagos sobre HTTP.
• En pagos, añade un rest-server que actúa como proxy hacia payments/core vía arranque.
• Comparte DTOs comunes en rest-common.
• Envuelve el cliente en el arranque de CRM.

Resultado: Un clúster con contextos acotados, donde los componentes escalan de forma independiente.

Componentes de plataforma

Extrae soluciones compartidas en una plataforma para seguir el principio DRY:

• Configuraciones de Postgres y TigerBeetle.
• Comunicación cliente/servidor REST.
• Autenticación, mensajería asíncrona/síncrona y almacenamiento.

La plataforma elimina duplicados: los componentes se conectan a setups listos para usar. Escala el reúso desde soluciones básicas hasta empresariales.

Beneficios y gobernanza

Los componentes imponen límites claros según la Ley de Conway: asígnalos a equipos y rastrea interacciones.

Gestión del ciclo de vida: Componentes pequeños son fáciles de cambiar y migrar.

Mantén el foco en requisitos: Las abstracciones te permiten elegir stacks según KPIs (rendimiento, costo), no por hábitos.

Cuándo usarla

Adóptala desde el día uno: de prototipos a sistemas distribuidos. Funciona con cualquier herramienta de compilación, escala a repos y equipos. Evita el 'enredo gigante' — los componentes permiten una evolución suave.

Lecciones clave:

• Directorios granulares como unidades de despliegue y responsabilidad.
• API/SPI para desacoplar de la infraestructura.
• Arranque para ensamblaje automático de contextos.
• Plataforma para máximo DRY y reúso.
• Transición fluida de monolito a microservicios sin refactorizar el núcleo.

— Editorial Team