Cada acción tiene responsable y deja registro.

La arquitectura sigue el servicio por cinco capas, desde la solicitud hasta el resultado aceptado.

De la solicitud al registro

Las capas de un servicio.

  1. 01

    Canales y recepción

    Recibir solicitudes por los canales acordados de clientes, colaboradores y sistemas.

  2. 02

    Coordinación del servicio

    Seguir el avance del caso, sus responsables y las acciones permitidas.

  3. 03

    Ejecución y agentes de IA

    Usar agentes de IA, modelos de IA y reglas aprobadas para hacer el trabajo.

  4. 04

    Sistemas de registro

    Actualizar o conciliar tus sistemas a través de interfaces autorizadas.

  5. 05

    Supervisión y evidencias

    Conservar los registros que miden la entrega, muestran las decisiones y permiten recuperarse.

En los módulos abiertos

Siete capas, de los canales a los sistemas de proveedores.

La arquitectura de Firefly en siete capas, de arriba abajo. Canales, donde empieza cada proceso. Procesos y decisiones: la IA actúa dentro de límites aprobados donde la normativa lo permite, y una persona con facultades delegadas decide los casos relevantes o fuera de límites. Módulos de Firefly, que operan el negocio. Datos y analítica. Integración: adaptadores conectados a la columna de API y eventos. Tus sistemas core, que se conservan y se conectan. Y los sistemas externos, siempre detrás de un adaptador.

Abre una capa para ver qué aporta y dónde termina.

01ExperienciasAPI de proceso para clientes y equipos operativos.

Los canales web y móviles, los portales de colaboradores y las herramientas operativas llaman a API de proceso, cada una con su punto de entrada.

  • exp-onboarding
  • exp-accounts
  • exp-distributor
02Dominios de negocioComandos, consultas y coordinación entre capacidades.

Los servicios de dominio coordinan los core; la saga de apertura enlaza contrato, titular, cuenta y primera transacción.

  • domain-banking-accounts
  • domain-customer-people
  • domain-product-catalog
03Registros y servicios coreAPI, modelos de datos y persistencia.

Cada módulo core es responsable de un registro, como un cliente, un contrato o una cuenta, tras contratos REST/OpenAPI.

  • core-common-customer-mgmt
  • core-common-contract-mgmt
  • core-banking-accounts
04Límites de integraciónSistemas externos, conectados en un solo sitio.

Las interfaces de proveedor dejan pagos, documentos, firma y sistemas de la aseguradora tras contratos explícitos, con tratamiento de errores y conciliación.

  • library-rails
  • library-psps
  • fireflyframework-ecm

Principios de diseño

Cómo se mantiene el trabajo bajo control.

Ajusta la tecnología a cada paso

Los agentes de IA llevan los casos de varios pasos; los modelos leen y redactan. Si un error cuesta caro, cálculos, permisos y asientos van con código determinista.

Diseña el camino de las excepciones junto al camino normal

Retrasos, evidencias ambiguas y fallos parciales son parte del proceso: el servicio define cómo pausar, reanudar y conciliar.

Mantén visibles las facultades de la entidad

Una acción propuesta no es una acción autorizada, y los límites delegados se aplican igual al trabajo automatizado y al humano.

Dentro de un servicio

Separa la lógica de negocio de sus conexiones.

Un puerto dice lo que necesita el caso de uso y un adaptador lo aporta, así que cambiar de base de datos o de proveedor no sale del adaptador.

Un servicio con puertos explícitos. En el centro, el caso de uso: una pieza ámbar con el modelo de dominio y, encima, las reglas de negocio. Recibe las peticiones por el conducto de API y publica eventos en el conducto ámbar para otros servicios. Detrás, en su propio terreno, la base de datos que guarda sus registros de negocio y un proveedor externo, cada uno accesible mediante una placa adaptadora de acero conectada a las API. Cambiar la base de datos o el proveedor supone cambiar su adaptador, no el caso de uso.Vista de referencia · un servicio con puertos explícitos
  1. 2
    Puerto de repositorio

    Persistir registros de negocio

    Base de datos relacional elegida
  2. 3
    Publicador de eventos

    Informar a otros servicios

    Broker de mensajes elegido
  3. 4
    Puerto de servicio externo

    Solicitar una acción al proveedor

    Adaptador a la API del proveedor

Decisiones de arquitectura

Diseña para toda la operativa.

Contratos de API

Define entradas, salidas, autorización y versiones, con reintentos idempotentes donde el servicio lo admita.

Datos y eventos

Elige qué servicio es dueño de cada registro y usa event sourcing donde aporte valor.

Estado de los procesos

Lleva el trabajo de larga duración a un runtime persistente: los temporizadores en memoria mueren con un reinicio.

Identidad y acceso

Separa quién es un usuario o servicio de lo que puede hacer, con OAuth2/JWT y contratos de políticas.

Evidencia operativa

Traza cada petición y acuerda cómo conciliar cuando un sistema externo actuó pero se perdió su respuesta.

IA dentro de límites

La salida del modelo es información tipada; los permisos y tu aprobación deciden qué avanza.

Fundamentos de ingeniería abiertos

Los frameworks que sustentan el diseño.

Firefly Framework aporta los patrones de servicios, datos, eventos, seguridad, procesos e IA que usa la plataforma.

Tu primera operativa

Tráenos una operativa.

Cuéntanos el proceso, el volumen y qué significa «terminado» para ti. Te enviaremos un alcance, un plan de despliegue y una propuesta.