从 mldong 到 jeeflow：一个工作流引擎的独立进化

系列开篇 · jeeflow 工作流引擎多语言联邦

如果你做过 Java 业务系统，大概率遇到过这种场景：

审批流、工作流，需求一来就是"上 Flowable / Activiti"。然后你就开始跟几 MB 的 jar、几百张表、一堆 XML/JSON 配置搏斗。为一个"请假审批"引一个"企业级引擎"，杀鸡用牛刀不说，学习成本、定制成本、升级成本，全都压在业务团队身上。

这是很多团队的现状，也是我们当年做 mldong 快速开发框架时的真实思考。今天这篇是jeeflow 系列的第一篇 ------我想完整讲清楚一件事：一个嵌入框架的工作流模块，是怎么一步步进化成"一套流程定义、四种语言实现"的独立引擎的。

本系列由 mldong 快速开发框架生态延续而来，公众号/掘金同步更新，欢迎关注追更。

起点：mldong 内置的自研工作流引擎

mldong 快速开发框架（开源在 Gitee 的 Java 快速开发框架）有个特点：能自研的不堆依赖。工作流就是其中之一。

在 Flowable 遍地走的时代，mldong 选择了自研一套基于 LogicFlow 流程图定义的轻量审批引擎：

流程定义用 LogicFlow JSON 描述（节点 + 边），可视化设计器画完，存的就是这份 JSON；
支持发起、审批、退回、跳转、会签、抄送、委托等完整审批语义；
业务扩展靠 AssignmentHandler（决定任务派给谁）和 FlowInterceptor（节点前后置钩子），业务逻辑不进引擎；
后端 Java 开源的两条主线（boot2 / boot3）的 wf 模块完全一致，前端配套 vben5 流程设计器，开箱即用。

在框架内部，这套引擎跑得很好：足够轻、足够稳，生态内的业务项目直接复用，不必重复造轮子。

转折：三个痛点，逼它"独立"

随着生态扩大，三个问题越来越尖锐：

痛点一：引擎和框架耦合，升级成本高。 mldong 框架本身有 boot2 → boot3 的"重写式"演进（框架结构不同，业务代码按逻辑重写），引擎跟着框架走，等于每次框架大版本升级，引擎也要跟着重写一遍。

痛点二：别的语言团队用不上。 生态里不只有 Java------还有 Python（FastAPI）、NestJS、前端 vben5。工作流的语义是通用的，但引擎长在 Java 框架里，其他技术栈只能"看着"。

痛点三：想开放出去，但带不动整个框架。 有人想单独用这套工作流引擎，但为了一个引擎去引入整个快速开发框架，太重了。

结论很清晰：引擎应该有独立的生命周期。它和框架的关系，应该从"内置模块"变成"上游 SDK"------框架是它的第一个消费者，而不是唯一的宿主。

独立：98KB 的引擎核心

于是有了 jeeflow ------ mldong 工作流模块的独立化版本。几个关键设计决策：

零框架依赖。 引擎核心（Java 版）只有 98KB ，依赖仅 slf4j-api（还是 provided）。不碰 Spring、不碰 MyBatis、不碰 Servlet。

SPI 化。 仓储、用户信息、JSON 解析、表达式求值、ID 生成、事务模板------6 大 SPI，引擎不假设你用什么技术栈，业务侧随意接入。想用 MyBatis 就用 MyBatis，想用内存仓储就跑单测，表达式想接自己的规则引擎也行。

DDD 充血模型。 ProcessInstance（聚合根）持有全部状态转换命令，ProcessTask（子实体）负责自己的行为。状态机明确：实例 10 进行中 / 20 已完成 / 45 已拒绝；任务 10 待办 / 20 已完成 / 99 已废弃。

契约对齐 mldong。 这是独立化最重要的一条------接口规范与 mldong 框架完全一致 ：响应 code=0 成功、msg 字段、submitType 全枚举（0 发起 / 1 同意 / 2 拒绝 / 3 退回上一步 / 4 跳转 / 5 重新提交 / 6 退回发起人 / 20 会签否决）、端点清单、VO 结构，全部对齐。这意味着：mldong 生态前端（vben5 + 流程设计器）可以直接对接 jeeflow，零改动。换芯不换壳，对消费方完全透明。

Spring Boot 2 / 3 / 4 三连 starter。 配套 autoconfigure，JDK 8 到 25 都能跑。

进化：一套流程定义，四种语言跑通

独立还不是终点。回到痛点二------其他语言团队怎么办？

我们的答案是多语言联邦 ：不搞"一个引擎的多种绑定"，而是四个独立实现 + 一份统一规范：

Java ：参考实现（jeeflow-java），一切行为的"标准答案"；
Go / Python / Node ：各自技术栈的原生实现（jeeflow-go / jeeflow-python / jeeflow-node）；
一份规范 （jeeflow-doc）：数据模型、流程定义格式、状态机、SPI、变量约定，唯一事实来源；
10 个共享流程 JSON ：简单审批、多级审批、决策表达式、并行分支合并、并行会签、串行会签、按比例会签、自定义节点、含驳回流程、混合模式------同一份流程定义，在四种语言上跑出相同结果；
统一前端 （jeeflow-ui）：Vue3 + 钉钉风格流程设计器，一套 UI 对接四套后端。

演进纪律很严格：规范先行 → Java 参考实现先改先测 → Go/Python/Node 对齐 → 交叉验证。任何语言改动，四个 demo 跑同一批流程验证，结果必须一致。

现在你打开四个演示站（Java :8080 / Go :8081 / Python :8100 / Node :8082），登录不同账号，跑同一份报销流程------流转结果一模一样。

现在：六个仓库的生态

bash 复制代码

jeeflow-hub/
├── jeeflow-java    # Java 参考实现（core 98KB + repository + 3 个 starter + demo）
├── jeeflow-go      # Go 实现（GoFrame demo）
├── jeeflow-python  # Python 实现（FastAPI demo）
├── jeeflow-node    # Node.js 实现（Express demo）
├── jeeflow-ui      # 统一前端（Vue3 + 钉钉流程设计器）
└── jeeflow-doc     # 规范与文档站（jeeflow-doc.mldong.com）

每处改动都要过三场景测试 ：正向（核心流程跑通）、负向（边界报错码符合预期）、回归（已有场景不破坏）。测试矩阵：Java core 14 + jdbc 5、Python spec 10 + e2e 34、Node 10。未测试的代码不允许提交------这条纪律贯穿所有语言。

这个系列，我要写什么

jeeflow 系列共四季，公众号 + 掘金同步：

季	主题	篇目
序章	从 mldong 到 jeeflow（本篇）	第 0 篇
第一季 · 认识	为什么自研、98KB 长什么样、状态机与 submitType	3 篇
第二季 · 核心设计	LogicFlow JSON、DDD 聚合根、applicant 契约、6 大 SPI、会签三兄弟	5 篇
第三季 · 多语言联邦	一套定义四语言跑通、跨语言对齐方法论、四实现对比	3 篇
第四季 · 生态实战	mldong 契约对齐、Spring Boot 2/3/4 starter、jeeflow-ui、报销流程实战、三场景测试	5 篇

下一篇预告：《为什么在 Flowable 时代还要写一个轻量工作流引擎》------自研 vs 主流开源引擎的完整选型对比，把"该不该自研"讲透。