← Volver al índice

Roadmap de Implementación — DKV Pet Flows

Tipo: Plan de Proyecto
Audiencia: Equipo de Desarrollo
Fecha: 25 de marzo de 2026
Fuente de verdad: dkv-pet-cloud (Health Connect = integración futurible)

Posicionamiento: Pet Flows añade la capa de Customer Engagement sobre Health Connect — no compite con el ESB sanitario, lo complementa con engagement multicanal.

---

Arquitectura de Dependencias (Critical Path)

graph TD
    subgraph "LAYER 0 - Modelo de Datos"
        A["Flow Model TypeScript + Zod"]
        B["Node Registry 40 nodos"]
    end

    subgraph "LAYER 1 - Paralelo FE + BE"
        C["Flow Canvas React Flow"]
        D["Node Catalog Panel"]
        E["Node Config Panel"]
        F["Quarkus REST API"]
        G["PostgreSQL Schema"]
    end

    subgraph "LAYER 2 - Integracion"
        H["FE-BE Connect TanStack Query"]
        I["Dapr Workflow Engine"]
    end

    subgraph "LAYER 3 - Engagement"
        J["Push Gorush"]
        K["Email Dapr Binding"]
        L["Execution Monitor SSE"]
    end

    subgraph "LAYER 4 - Inteligencia"
        M["AI Nodes LangChain4j"]
        N["Analytics Dashboard"]
    end

    A --> C & D & E & F & G
    B --> C & D & E
    C & D & E --> H
    F & G --> H
    H --> I
    I --> J & K & L
    L --> N
    I --> M

Clave: Layer 0 desbloquea TODO. Layer 1 es 100% paralelo.

---

Resumen de Sprints

Sprint	Duración	SP	Paralelo con	Output Principal
S0 Fundaciones	1 sem	13	—	Tipos + Registry → desbloquea todo
S1A Frontend Canvas	2 sem	35	S1B	Flow Builder visual drag-and-drop
S1B Backend API	2 sem	31	S1A	REST API + PostgreSQL
S2 Integración	1 sem	13	—	FE↔BE conectados
S3A Motor Ejecución	2 sem	35	S3B	Dapr Workflows operativos
S3B Canales	2 sem	27	S3A	Push + Email + SMS
S4 Monitor	1.5 sem	23	—	SSE + Analytics
S5 IA	2 sem	24	—	Nodos IA diferenciadores
TOTAL		201 SP

Calendario con Paralelismo

Semana:  1    2    3    4    5    6    7    8    9
         ┌──┐
  S0     │██│ Fundaciones
         └──┘
              ┌────────────┐
  S1A         │████████████│ Frontend Canvas
              └────────────┘
              ┌────────────┐
  S1B         │████████████│ Backend API        ← PARALELO
              └────────────┘
                            ┌──┐
  S2                        │██│ Integración
                            └──┘
                                ┌────────────┐
  S3A                           │████████████│ Motor Ejecución
                                └────────────┘
                                ┌────────────┐
  S3B                           │████████████│ Canales          ← PARALELO
                                └────────────┘
                                              ┌─────┐
  S4                                          │█████│ Monitor
                                              └─────┘

Secuencial: 12.5 semanas ≈ 3 meses
Paralelo:    8.5 semanas ≈ 2 meses (ahorro 32%)

---

Sprint 0 — Fundaciones (1 semana)

#	Story	SP	Prioridad
0.1	Definir FlowDefinition TypeScript types (Node, Edge, Flow, Execution)	3	Must
0.2	Crear Zod schemas para validación de cada tipo de nodo	3	Must
0.3	Crear NodeRegistry con metadata de los 40 nodos	5	Must
0.4	Scaffolding packages/flow-engine/ con exports	2	Must

---

Sprint 1A — Frontend Canvas (2 semanas)

#	Story	SP	Prioridad
1A.1	FlowCanvas component con React Flow, grid, zoom, minimap	5	Must
1A.2	Custom Node components (5 categorías × estilo visual)	8	Must
1A.3	NodeCatalogPanel sidebar con búsqueda y drag-and-drop	5	Must
1A.4	NodeConfigPanel slide-out con formularios dinámicos	8	Must
1A.5	Zustand stores: useFlowStore + useCanvasStore	3	Must
1A.6	Undo/Redo con Zustand temporal middleware	3	Should
1A.7	Validación visual: nodos sin conexión, edge validation	3	Should

---

Sprint 1B — Backend API (2 semanas)

#	Story	SP	Prioridad
1B.1	PostgreSQL schema: flow_definition, flow_version (JSONB)	5	Must
1B.2	Quarkus REST: CRUD /api/flows	8	Must
1B.3	Quarkus REST: /api/flows/{id}/validate	3	Must
1B.4	Quarkus REST: /api/flows/{id}/execute vía Dapr	5	Must
1B.5	PostgreSQL schema: flow_execution, execution_step	3	Must
1B.6	Versioning de flows: cada save crea nueva versión	5	Should
1B.7	Java sealed classes para estados de ejecución	2	Should

---

Sprint 2 — Integración FE↔BE (1 semana)

#	Story	SP	Prioridad
2.1	TanStack Query hooks: useFlows, useFlowById, etc.	5	Must
2.2	Auto-save flow cada 30s + save manual	3	Must
2.3	Serialización React Flow ↔ API JSON	3	Must
2.4	Indicador de estado de conexión	2	Should

---

Sprints 3–5 (detalle reducido)

S3A — Motor de Ejecución (2 sem, 35 SP)

• Dapr Workflow: interpretar flow_definition → actividades
• Nodos Trigger: Webhook, Cron, Evento API
• Nodos Lógica: If/Else, Wait, Router
• Event sourcing + Circuit breaker

S3B — Canales de Comunicación (2 sem, 27 SP)

• Gorush: Push APNs + FCM con rich content
• Email Dapr Binding: SMTP/SendGrid
• SMS Dapr Binding: Twilio/Vonage
• In-App Message + Inbox

S4 — Monitor + Analytics (1.5 sem, 23 SP)

• SSE endpoint para eventos de ejecución
• Execution Monitor UI: progreso nodo por nodo
• Campaign Analytics: delivery, open, click, conversion

S5 — IA (2 sem, 24 SP)

• IA: Generar Contenido (LangChain4j → Azure OpenAI)
• IA: Best Time to Send, Sentiment, Clasificar, Recomendar

---

Análisis de Riesgos

Riesgo	Prob.	Impacto	Mitigación
dkv-pet-cloud API no documentada	M	H	Spike de 2 días al inicio de S3A
Gorush setup complejo (APNs certs)	M	M	Usar FCM-only en dev
Dapr Workflow learning curve (Java)	M	H	Prototipar workflow simple en S0
React Flow performance >50 nodos	L	M	Virtualización + lazy rendering
LangChain4j + Azure OpenAI latencia	M	M	Timeout + fallback templates

---

Documentos Relacionados

Nivel	Documento	Descripción
Librería	Jaraxa	Arquitectura de la librería visual
Nodos	Catálogo 40 Nodos	Tipos, colores, fuentes de datos
Especificación	Flow Builder	Requisitos UX del editor