Saltar a contenido

Architecture Decision Records

Decisiones arquitectónicas significativas tomadas durante el análisis de Camunda 8 y diseño del MVP simplificado. Formato MADR (Markdown Architectural Decision Records). Cada ADR documenta contexto, alternativas evaluadas, decisión, y consecuencias.

Status legend

  • 🟢 Accepted — decisión vigente
  • 🟡 Proposed — sugerida, pendiente de validación
  • 🔴 Deprecated — superseded por otra ADR
  • ⚪ Superseded — reemplazada por una nueva

Index

Core engine

# Título Status
adr 001 bpmn as workflow language BPMN 2.0 como lenguaje de workflow 🟢 Accepted
adr 002 postgresql as state store PostgreSQL como state store único 🟢 Accepted
adr 003 single node mvp incremental scaling Single-node MVP, escalar incrementalmente 🟢 Accepted
adr 004 no fork consensus protocols NO forkear protocolos de consensus 🟢 Accepted
adr 005 stream processing command sourcing Stream processing con command sourcing 🟢 Accepted
adr 006 single threaded per partition Single-threaded processing por partition 🟢 Accepted
adr 007 at least once idempotent workers At-least-once delivery, workers idempotentes 🟢 Accepted
adr 019 replay determinism invariant Replay determinism como invariante testeable 🟢 Accepted

Webapps & UI

# Título Status
adr 008 reuse camunda modeler Reusar Camunda Modeler (no rebuild) 🟢 Accepted
adr 009 skip optimize use grafana Skip Optimize, usar Grafana + SQL 🟢 Accepted
adr 010 hybrid monitoring apm inspector Hybrid monitoring: APM + Process Inspector 🟢 Accepted
adr 018 build tasklist completo Build Tasklist completo (no skipeable) 🟢 Accepted

Identity & Security

# Título Status
adr 013 simple rbac three roles RBAC simple: 3 roles (admin/operator/worker) 🟢 Accepted
adr 014 oidc single idp OIDC single IdP en Phase 1 🟢 Accepted

Integration

# Título Status
adr 015 skip inbound connectors Skip inbound connectors, usar REST API 🟢 Accepted
adr 016 minimal outbound worker sdk SDK outbound minimal (no framework) 🟢 Accepted

Data & Serialization

# Título Status
adr 012 json schema forms JSON Schema para forms 🟢 Accepted
adr 017 json serialization not sbe JSON serialization (no SBE/MessagePack) 🟢 Accepted

Infrastructure & Operations

# Título Status
adr 011 opentelemetry instrumentation OpenTelemetry para instrumentación 🟢 Accepted
adr 020 patroni postgres ha Patroni para Postgres HA (Phase 1) 🟢 Accepted
adr 021 citus horizontal scaling Citus para horizontal scaling (Phase 4) 🟡 Proposed

Core engine (continued)

# Título Status
adr 022 cel for expressions CEL para expressions (con FEEL-lite shim) 🟢 Accepted

Identity & Security (continued)

# Título Status
adr 023 tls only production TLS 1.3 mandatory en producción 🟢 Accepted
adr 024 postgres rls defense in depth Postgres RLS as defense in depth 🟢 Accepted
adr 025 audit logging mandatory Audit logging mandatory para security ops 🟢 Accepted

Technology Stack

# Título Status
adr 026 go as implementation language Go como lenguaje de implementación (engine + CLI) 🟢 Accepted

Por categoría — vista de árbol

ADRs/
├── Core engine (8)
│   ├── ADR-001 BPMN 2.0
│   ├── ADR-002 PostgreSQL store
│   ├── ADR-003 Single-node MVP
│   ├── ADR-004 No fork consensus
│   ├── ADR-005 Stream processing
│   ├── ADR-006 Single-threaded
│   ├── ADR-007 At-least-once
│   └── ADR-019 Replay determinism
│
├── Webapps & UI (4)
│   ├── ADR-008 Reuse Modeler
│   ├── ADR-009 Skip Optimize
│   ├── ADR-010 Hybrid monitoring
│   └── ADR-018 Build Tasklist
│
├── Identity & Security (2)
│   ├── ADR-013 RBAC 3 roles
│   └── ADR-014 OIDC single IdP
│
├── Integration (2)
│   ├── ADR-015 Skip inbound connectors
│   └── ADR-016 Minimal outbound SDK
│
├── Data & Serialization (2)
│   ├── ADR-012 JSON Schema forms
│   └── ADR-017 JSON serialization
│
└── Infrastructure & Ops (3)
    ├── ADR-011 OpenTelemetry
    ├── ADR-020 Patroni HA
    └── ADR-021 Citus scaling

Total: 21 ADRs.

Cómo usar este directory

Para review

  • Leer el index para overview rápido
  • Cada ADR es self-contained (~1-2 pages)
  • Cross-references vía wikilinks

Para proponer cambio

  1. Crear nuevo ADR con número siguiente
  2. Status: Proposed
  3. Si supersedes a otro ADR existente, marcar el viejo como Deprecated y referenciar

Para implementación

Los ADRs son inputs al planning, no especificación detallada. Para implementación ver: - blueprint plataforma simplificada — Spec técnico - scaling strategy postgres — Roadmap de fases - operate tasklist mvp detailed — Spec de webapps

Formato MADR

Cada ADR sigue el formato MADR 2.x:

# ADR-NNNN: Título

* Status: Accepted | Proposed | Deprecated | Superseded
* Date: YYYY-MM-DD
* Tags: relevant tags

## Context and Problem Statement
## Decision Drivers
## Considered Options
## Decision Outcome
### Positive Consequences
### Negative Consequences
## Pros and Cons of the Options
## Links

Referencias