Saltar a contenido

ADR-001: BPMN 2.0 como lenguaje de workflow

  • Status: Accepted
  • Date: 2026-05-14
  • Tags: core, workflow-definition

Context and Problem Statement

El MVP necesita un lenguaje para definir workflows ejecutables. La elección impacta target audience, tooling, performance, y compatibility con sistemas existentes. ¿Usamos BPMN visual standard, código como Temporal, JSON DSL como Conductor, o algo custom?

Decision Drivers

  • MVP debe ser "drop-in replacement de Camunda 8" → BPMN compatibility es requirement
  • Usuarios objetivo incluyen business analysts (no solo developers)
  • Compliance/audit en industrias reguladas requiere modelos visuales documentables
  • Standard ISO existente (BPMN 2.0) reduces vendor lock-in
  • Tooling maduro (Camunda Modeler, bpmn-js) ya existe

Considered Options

  1. BPMN 2.0 XML (como Camunda 8)
  2. Code-first (como Temporal — workflows como funciones Go/Java/TS/Python)
  3. JSON DSL (como Netflix Conductor)
  4. YAML K8s-native (como Argo Workflows)
  5. Custom DSL propietario

Decision Outcome

Chosen option: BPMN 2.0 XML porque: - Es requirement del MVP target (drop-in Camunda) - Permite usuarios no-técnicos modelar procesos - Tooling externo (Modeler) maduro existe - bpmn-js MIT-licensed para viewer/embedding - ISO standard reduce vendor lock-in

Positive Consequences

  • Compatibility con Camunda Modeler (no rebuild — ver ADR-008)
  • Business analysts pueden colaborar en diseño
  • Compliance/audit straightforward (modelos visuales)
  • Migration desde Camunda 8 es viable
  • Standard que sobrevivirá long-term

Negative Consequences

  • Performance ligeramente menor que code-first (BPMN interpretation overhead)
  • Verboso comparado con JSON DSL
  • Spec BPMN tiene complexity inherente (54 element types, sólo soportamos ~20)
  • Type safety menor que code-first (XML strings vs typed code)

Pros and Cons of the Options

BPMN 2.0 XML

Pros: - Standard ISO 19510 - Visual + executable simultáneamente - Tooling existente (Modeler, bpmn-js, Camunda ecosystem) - Business stakeholders pueden colaborar - Migration path desde Camunda 7/8 / TIBCO / IBM BPM

Cons: - Verboso (XML) - Performance overhead (~single-digit ms por element interpretation) - Subset support requerido (no implementaremos los 54 element types)

Code-first (Temporal-style)

Pros: - Performance superior (sub-ms) - Type-safe en compile time - Familiar para developers - Refactor-friendly - Versioning natural (git)

Cons: - Rompe el contrato MVP "drop-in Camunda" - Excluye business analysts - Polyglot SDK requiere massive eng investment - Sin standard inter-vendor

JSON DSL (Conductor-style)

Pros: - Conciso (vs XML) - Dev-friendly - Deployable como config (GitOps)

Cons: - Sin standard ISO - Sin visual modeling first-class - Migration desde Camunda imposible - Stakeholders no-técnicos limitados

YAML K8s-native (Argo-style)

Pros: - K8s-native - Container-as-step

Cons: - Target use case diferente (containerized pipelines) - Sin human tasks support - Sin BPMN compatibility

Custom DSL

Pros: - Optimizable para use case - Sin restrictions de standards

Cons: - Vendor lock-in worst case - No ecosystem, no tooling existing - Curva de aprendizaje para nuevos users - Mantener parser/validator es costo permanente