← Volver al índice | Anterior: Motor de Flujos
Decisión de Arquitectura: Dapr vs Pekko & Quarkus vs Spring Boot¶
Tipo: Documentación Técnica — Core Architecture
Audiencia: Ingeniería (Arquitectura, Backend)
Fecha: 04 de Abril de 2026
1. El Salto desde el Modelo de Actores (Pekko)¶
En desarrollos anteriores del ecosistema dkv-pet-cloud, la orquestación distribuida se resolvía utilizando Spring Boot + Apache Pekko (Modelo de Actores). Para dkv-pet-flows, se tomó la decisión unánime de migrar la capa de orquestación a Dapr Workflows.
Esta decisión se basa en la reducción radical del boilerplate y de la curva de aprendizaje en torno al manejo de estado.
¿Por qué Dapr vence a Pekko para flujos de negocio?¶
En el Modelo de Actores:
- El código se estructura mediante máquinas de estados (Finite State Machines), buzones de mensajes (Receive) y jerarquías de supervisión.
- Un proceso que dura días (ej. esperar la respuesta de un paciente) requiere guardar manualmente el estado con PersistentActor (Event Sourcing) y gestionar a mano temporizadores auto-enviados.
En Dapr Workflows (Workflow as Code):
- Desaparecen los buzones y las máquinas de estado programadas manualmente.
- Se utiliza el Durable Task Framework. La orquestación se escribe como un bloque de código lineal de Java (loops, if, try-catch).
- Dapr inyecta puntos de suspensión duraderos: si llamas a createTimer(2 días), el framework intercepta la llamada, serializa las variables locales de tu método a la base de datos, destruye el hilo de Java para liberar memoria, y lo resucita exactamente en la misma línea a los dos días repitiendo los pasos (Replay) usando el estado capturado.
Beneficio final: Menos del 20% de las líneas de código equivalentes en Pekko, y nula gestión de dead-letters y retries (que están manejados automáticamente por las Activities).
2. La Regla de Oro: Workflow vs Activity¶
Dapr exige que dividamos la lógica en dos tipos de clases muy marcadas para lograr el "Dinamismo Estático".
- Workflow (El Orquestador): Es la mente maestra. Debe ser 100% Determinista. Tiene estrictamente prohibido usar funciones random, generar UUIDs o hacer peticiones HTTP directas. ¿Por qué? Porque si se cae y se levanta ("Replay"), al re-ejecutarse desde el inicio la rama
ifno debe comportarse diferente. - Activity (El Worker): Hace el trabajo sucio (DB, HTTP). No es determinista. Cuando el Workflow invoca una Activity, Dapr guarda la salida en el disco. Si el Workflow hace "Replay", no se vuelve a invocar a la Activity, se devuelve instantáneamente el valor que se leyó de disco en su momento.
3. Quarkus vs Spring Boot¶
La otra decisión crucial evaluada fue mantener el soporte de la integración Dapr.
- Dapr en Quarkus (
quarkus-dapr): Ecosistema Preview mantenido comunitariamente (Quarkiverse). Brinda excelente experiencia de desarrollo local arrancando los sidecars automáticamente (Dev Services), además del ridículo consumo de RAM y su arranque instantáneo al usarse en Kubernetes nativo. - Dapr en Spring Boot (
dapr-spring-boot-starter): Oficializado por los desarrolladores de Dapr. Trae integración profunda con dependencias Spring, pero su consumo de recursos es tradicional.
Inmutabilidad del Código ("Workflow as Code")¶
La verdadera fortaleza de esta arquitectura es que el código de negocio es ciego al framework subyacente (Quarkus/Spring).
Ambos usan las mismas clases exactas proporcionadas por el dapr-java-sdk-workflow. Esto significa que si el equipo de arquitectura decide migrar a Spring Boot por familiaridad general del equipo de desarrolladores (y para evitar inestabilidades en DevServices de Quarkus), el 100% de la lógica de los Flujos (Workflows y Activities) se mantiene intacta sin modificar ni un solo import.
Documentos Relacionados¶
| Nivel | Documento | Descripción |
|---|---|---|
| Concepto | Motor de Flujos Dinámicos (Patrón Intérprete) | Análisis del motor que permite mapear un grafo visual a un Workflow Dapr |
| Pico (Spike) | Spike Dapr Workflows | Informe original de viabilidad sobre el "Workflow-as-code" |