Saltar a contenido

← Volver al índice | Arquitectura del Sistema

Investigación Estratégica: DKV Pet Cloud

Tipo: Investigación técnica y estratégica Audiencia: Equipo técnico, Product Owner Fecha: 26 marzo 2026


Visión General de dkv-pet-cloud

dkv-pet-cloud es un monolito modular basado en Spring Boot 3.5.9 / Java 25 con capacidades distribuidas a través de Apache Pekko (cluster, sharding, persistence). Es el sustituto progresivo de netcomp (Erlang).

Stack Tecnológico Principal

Capa Tecnología Versión Notas
Runtime Java 25 Maven, multi-module
Framework Spring Boot 3.5.9 Jetty
Clustering Apache Pekko 1.2.0 Actor model, Scala 3
Base de Datos PostgreSQL 15.6 Liquibase para migraciones
Search/Index Elasticsearch 7.17.28 Hibernate Search 7.2.2
Mensajería RabbitMQ Local build AMQP + STOMP (puerto 61613)

Contexto de Negocio Crítico: Casos Médicos (Encounters)

La entidad de negocio más importante es el Caso Médico (Encounter). La auditoría del código Java confirma que dkv-pet-cloud gestiona nativamente esta entidad mediante EncounterController, con soporte para eventos distribuidos mediante Pekko Streams (CREATE_ENCOUNTER_EVENT).


El Reto Crítico — Migración Netcomp a Pet Cloud (GoLive)

El desafío arquitectónico más complejo y de mayor riesgo no es la inserción de dkv-pet-flows, sino la transición del núcleo transaccional.

El Abismo de Datos

  • netcomp opera con persistencia 100% sobre Elasticsearch 6.
  • dkv-pet-cloud opera sobre PostgreSQL para persistencia garantizada + Elasticsearch 7 (vía Hibernate Search) para indexación.

Estrategia: Leader/Follower Bidireccional (RabbitMQ)

Para el GoLive prolongado, se establece un sistema Leader/Follower:

  • Cada vez que una entidad muta en cualquiera de los dos sistemas, se despacha un payload (una "foto" completa del estado de la entidad) a través de RabbitMQ.
  • Las garantías de reliability (ACKs, DLQs) de RabbitMQ aseguran que los mensajes bidireccionales repliquen los datos a la perfección entre el ES6 legado y PG/ES7 moderno.
  • Esto permite validaciones de consistencia exhaustivas antes de designar a dkv-pet-cloud como el Máster absoluto.

Integración dkv-pet-flows y Ecosistema

Mientras el GoLive de netcomppet-cloud exige máxima atención, el MVP Backlog de dkv-pet-flows (basado en Quarkus+Dapr) debe introducir valor de forma "silenciosa y controlada".

Mecanismo de Flujos Veredicto Justificación Estratégica
REST (Salida) Elegido Usar la fachada dkv-pet-proxy para llamadas de acción síncronas (ej. enviar comandos, SMS batch). Verificada la total paridad REST entre el Proxy y los @Controller de Spring.
Webhooks (Entrada) Elegido Ingesta de datos limpia.
OpenAI / IA 🕒 Retrasado Delegar la complejidad volumétrica y governance IA para una fase post-MVP Backlog.

Ingesta de Eventos (Netcomp → Flows) vía Webhooks

En dkv-pet-admin existe una propiedad en la entidad Queue (Cola) denominada webhook_new_message_recipients. Netcomp despacha notificaciones orgánicamente hacia estas URLs (concebido originalmente para integrar pools médicos de terceros).

Decisión MVP Backlog

dkv-pet-flows expondrá un Ingress HTTP normal, y dkv-pet-admin configurará esa URL. Netcomp inyectará los payloads de actividad médica directamente en flows sin que haya que programar ni una línea en Erlang.


Absorción de DTM (Distributed Task Manager)

Para conseguir una suite unificada donde orquestar y observar TODAS las planificaciones del sistema, dkv-pet-flows asimilará las responsabilidades del planificador aislado Quartz (distributed-task-manager).

Estrategia Elegida: Strangler Fig ("Silence & Wait")

  • Cómo opera: DTM deja de absorber nueva carga, pero sigue corriendo.
  • Todo nuevo scheduling se enruta a los Cron Bindings/Timers de dkv-pet-flows.
  • Las tareas históricas de Quartz expiran orgánicamente o se ejecutan por última vez en la BD de DTM.
  • Finalmente, el contenedor DTM se degrada y apaga sin trauma operativo ni riesgos de ETL.

Documentos Relacionados

Nivel Documento Descripción
Arquitectura Arquitectura del Sistema Visión general del stack
Arquitectura Auditoría: dkv-notifications Análisis del servicio de notificaciones Erlang
Arquitectura Spike: Dapr Workflows Evaluación de Dapr como motor de flujos
Planificación Roadmap Sprints Planificación por sprints