Estructura del Monorepo y Módulos de Camunda 8¶

Resumen: Camunda 8 se organiza como un monorepo Maven con jerarquía camunda-bom → zeebe-parent → camunda-8-root, conteniendo 50+ submodules solo en zeebe/. El codebase totaliza ~1.65M líneas de Java y ~260K de TypeScript, usando Spring Boot 4.0.6, Elasticsearch 8.19, RocksDB 10.9.1, y gRPC 1.80. El módulo dist/ es el artifact deployable, configuration/ actúa como wiring central, y destaca gateway-mcp como integración con Spring AI MCP.

Jerarquía Maven¶

Tres niveles de POMs¶

El monorepo usa una jerarquía de tres niveles de POMs Maven:

flowchart TD
    BOM[camunda-bom<br/>Bill of Materials] --> ZP[zeebe-parent]
    ZP --> Root[camunda-8-root]
    Root --> Zeebe["zeebe/ (50+ modules)"]
    Root --> Operate[operate/]
    Root --> Tasklist[tasklist/]
    Root --> Optimize[optimize/]
    Root --> Identity[identity/]
    Root --> Connectors[connectors/]
    Root --> Webapps[webapps-common/]
    Root --> Search[search/]
    Root --> Dist[dist/]
    Root --> Other[...]

camunda-bom¶

Propósito: centralizar la gestión de versiones de TODAS las dependencias del proyecto.
Tipo: POM de tipo bom (Bill of Materials).
Uso: cualquier módulo que declare <parent> o <dependencyManagement> referencia este BOM para obtener versiones consistentes de todas las dependencias.
Dependencias gestionadas: Spring Boot, Elasticsearch, gRPC, Netty, Jackson, Protobuf, RocksDB, y cientos más.

zeebe-parent¶

Propósito: configuración compartida para los módulos de Zeebe (el engine core).
Contenido: plugins de Maven (compiler, surefire, spotless), configuración de lint/format, profiles de build.
Herencia: todos los módulos bajo zeebe/ heredan de este parent.

camunda-8-root¶

Propósito: POM raíz que define la estructura del monorepo.
Tipo: POM reactor — coordina el build de todos los módulos.
Profiles: profiles para builds parciales (solo engine, solo webapps, solo tests de integración).

Los 50+ submodules de zeebe/¶

El directorio zeebe/ contiene el engine core y sus componentes asociados. Los módulos principales, organizados por función:

Core del engine¶

Módulo	Función
`zeebe/engine`	Stream processor, state machine, command processors
`zeebe/engine-processing-shared`	Interfaces compartidas de procesamiento
`zeebe/logstreams`	Log stream abstraction (append-only log)
`zeebe/stream-platform`	Plataforma de streaming sobre el log
`zeebe/journal`	Implementación del journal (log persistente)

Networking y protocolo¶

Módulo	Función
`zeebe/gateway`	Gateway gRPC/REST, entry point para clientes
`zeebe/gateway-protocol`	Definiciones Protobuf de la API gRPC
`zeebe/gateway-protocol-impl`	Implementación del protocolo
`zeebe/gateway-rest`	API REST del gateway
`zeebe/gateway-mcp`	Integración con Spring AI MCP
`zeebe/transport`	Capa de transporte entre nodos del cluster
`zeebe/protocol`	Protocolo interno de Zeebe (SBE-based)
`zeebe/protocol-impl`	Implementación del protocolo interno

Storage¶

Módulo	Función
`zeebe/zb-db`	Abstracción sobre RocksDB, column families
`zeebe/snapshots`	Gestión de snapshots de RocksDB

Clustering¶

Módulo	Función
`zeebe/atomix`	Implementación de Raft (fork de Atomix)
`zeebe/dynamic-config`	Configuración dinámica del cluster
`zeebe/topology`	Gestión de topología del cluster

Exporters¶

Módulo	Función
`zeebe/exporters/elasticsearch-exporter`	Exportador a Elasticsearch
`zeebe/exporters/opensearch-exporter`	Exportador a OpenSearch
`zeebe/exporters/camunda-exporter`	Exportador unificado de Camunda
`zeebe/exporters/rdbms-exporter`	Exportador a RDBMS

Modelo y lenguaje¶

Módulo	Función
`zeebe/bpmn-model`	Parser y modelo de BPMN 2.0
`zeebe/dmn`	Integración con el DMN engine
`zeebe/feel`	Integración con FEEL (expression language)
`zeebe/msgpack-value`	Serialización MessagePack para variables

Testing y utilidades¶

Módulo	Función
`zeebe/test-util`	Utilidades de testing compartidas
`zeebe/qa`	Tests de integración y QA
`zeebe/benchmarks`	Benchmarks de rendimiento
`zeebe/broker`	Configuración y bootstrap del broker

Key technologies y versiones¶

Tecnología	Versión	Uso
Spring Boot	4.0.6	Framework base para todos los componentes
Elasticsearch	8.19	Backend de búsqueda y almacenamiento de datos exportados
RocksDB	10.9.1	State store del engine (via JNI)
gRPC	1.80	Protocolo de comunicación cliente-broker
Protobuf	3.x / 4.x	Serialización de mensajes gRPC
Netty	4.x	Networking (bajo gRPC y transporte interno)
SBE (Simple Binary Encoding)	1.x	Serialización del protocolo interno (ultra-fast, zero-copy)
MessagePack	msgpack-java	Serialización de variables de proceso
Jackson	2.x	JSON serialización para REST APIs
FEEL engine	custom	Evaluación de expresiones FEEL
Atomix (fork)	custom	Consenso Raft para replicación
Guava	33.x	Utilidades (RateLimiter, caches, collections)

Métricas de código¶

Lines of Code (LOC)¶

Lenguaje	LOC aproximado	Uso principal
Java	~1,650,000	Engine, gateway, exporters, webapps backend, search
TypeScript	~260,000	Operate UI, Tasklist UI, Optimize UI
Protobuf	~5,000	Definiciones de API gRPC
XML/YAML	~50,000	Configuraciones, test resources, BPMN fixtures

Distribución por componente (Java estimado)¶

Componente	% del código Java
Zeebe engine + modules	~45%
Operate	~15%
Tasklist	~10%
Search infrastructure	~10%
Identity + security	~8%
Connectors	~7%
Optimize	~5%

dist/: artifact deployable¶

El módulo dist/ es el artifact final deployable de Camunda 8:

Contenido¶

dist/
├── pom.xml
├── src/main/
│   ├── java/           # Bootstrap class
│   └── resources/
│       ├── application.yaml    # Configuración default
│       └── ...
└── target/
    └── camunda-zeebe-*.tar.gz  # Distribution artifact

Función¶

Agrega todos los módulos necesarios como dependencias Maven.
Genera el artifact deployable (tar.gz, Docker image).
Configura Spring Boot con el application context completo.
Define profiles de runtime: standalone (todo en uno), broker-only, gateway-only.

Modos de deployment¶

# Standalone: todo en un proceso JVM
java -jar camunda-zeebe.jar

# Solo broker
java -jar camunda-zeebe.jar --spring.profiles.active=broker

# Solo gateway
java -jar camunda-zeebe.jar --spring.profiles.active=gateway

configuration/: wiring central¶

El módulo configuration/ actúa como el punto central de wiring de Spring:

Responsabilidad¶

configuration/
├── BrokerConfiguration.java
├── GatewayConfiguration.java
├── ExporterConfiguration.java
├── IdentityConfiguration.java
├── SearchConfiguration.java
├── WebappsConfiguration.java
└── ...

Beans de Spring: define los @Bean que conectan todos los módulos.
Condicionales: usa @ConditionalOnProperty y @Profile para habilitar/deshabilitar componentes.
Orden de inicialización: define dependencias entre beans y orden de startup.
Configuración externalizada: mapea properties de application.yaml a objetos de configuración.

Ejemplo de wiring¶

@Configuration
@ConditionalOnProperty(name = "camunda.broker.enabled", havingValue = "true")
public class BrokerConfiguration {

    @Bean
    public StreamProcessor streamProcessor(
        ZeebeDb zeebeDb,
        LogStream logStream,
        CommandProcessors processors) {
        return new StreamProcessor(zeebeDb, logStream, processors);
    }

    @Bean
    @ConditionalOnProperty(name = "camunda.broker.exporters.elasticsearch.enabled")
    public ElasticsearchExporter esExporter(ElasticsearchConfig config) {
        return new ElasticsearchExporter(config);
    }
}

gateway-mcp: Spring AI MCP integration¶

Qué es¶

El módulo gateway-mcp es una integración con Spring AI MCP (Model Context Protocol), permitiendo que LLMs interactúen con Camunda como un tool provider:

Funcionalidad¶

Expone capacidades de Camunda como MCP tools que un LLM puede invocar.
Permite operaciones como:
Consultar process instances.
Iniciar nuevos procesos.
Completar user tasks.
Consultar incidents.
Usa el estándar MCP para interoperabilidad con cualquier LLM client compatible.

Significado arquitectónico¶

Este módulo es notable porque:

AI-native workflow: indica la dirección de Camunda hacia integración nativa con AI agents.
MCP como estándar: adopta el protocolo MCP como interfaz de integración con LLMs.
Spring AI: usa el framework Spring AI, que está alineado con la stack tecnológica de Camunda (Spring Boot).

Grafo de dependencias internas¶

flowchart TD
    GRest[gateway-rest] --> GW[gateway]
    GW --> GProto[gateway-protocol]
    Broker[broker] --> Engine[engine]
    Engine --> EP[engine-processing]
    EP --> ES[engine-state]
    Engine --> BPMN[bpmn-model]
    Engine --> Proto[protocol]
    Broker --> Atomix[atomix/raft]
    Atomix --> LS[logstream]
    LS --> ZDB[zeebedb — RocksDB]
    Broker --> ExpAPI[exporter-api]
    ExpAPI --> ESExp[elasticsearch-exporter]
    ExpAPI --> CExp[camunda-exporter]
    ExpAPI --> SC["search-client-*"]
    SC --> Webapps[operate/tasklist/optimize]

El engine es el centro gravitacional: todo depende de él directa o indirectamente.

Consideraciones para un MVP¶

Esencial: una estructura de módulos clara (engine, gateway, storage, exporters) es fundamental para mantenibilidad. No intentar poner todo en un solo módulo.
Simplificable: la jerarquía de tres niveles de POMs (bom → parent → root) es overkill para un MVP. Un solo POM parent con modules es suficiente.
Simplificable: los 50+ submodules de Zeebe pueden consolidarse dramáticamente. Un MVP necesita ~8-10 módulos: engine, gateway, protocol, storage, exporter, model, config, app.
Recomendado: el patrón dist/ como artifact deployable es una buena práctica desde el inicio.
Recomendado: configuration/ como wiring central con Spring Boot facilita la modularidad y el testing.
Diferible: gateway-mcp es interesante pero no esencial para un MVP. Puede agregarse como módulo opcional después.
Referencia: las versiones de dependencias (Spring Boot 4.0.6, ES 8.19, RocksDB 10.9.1, gRPC 1.80) son un buen punto de partida para elegir dependencias del MVP.

Una plataforma simplificada puede reducir los 50+ módulos a ~8-10:

core — engine + state (reemplaza engine, engine-processing, engine-state, zeebedb)
bpmn — parser + modelo (reemplaza bpmn-model)
api — REST endpoints (reemplaza gateway, gateway-rest, gateway-protocol)
storage — PostgreSQL adapter (reemplaza atomix, raft, logstream, zeebedb)
worker — job worker system (reemplaza parte de broker)
exporter — CDC simple (reemplaza exporter-api + implementaciones)
monitor — dashboard/CLI (reemplaza operate, search/)
auth — OIDC + RBAC (reemplaza identity)

Ver analysis/mvp-feature-matrix para el desglose detallado de features por tier.