第三章. 架构瘦身：可选模块（Workflow）移除

第三章. 架构瘦身：可选模块（Workflow）移除实战

摘要：本章我们将进行一次“架构瘦身”实战。鉴于工作流（Workflow）并非所有项目的必选项，本章将手把手带你从项目中 彻底剥离 ruoyi-workflow 模块。内容涵盖 IDEA 模块移除、Maven 依赖清理、application-dev.yml 配置精简，以及数据库相关表的清除，帮助你打造一个更轻量、启动更快的后端服务。

本章学习路径

Workflow 模块移除

我们将按照一个安全、彻底的剥离路径来移除工作流模块，确保项目“一身轻松”：

3.1. 为什么要移除工作流

在第二章中，我们成功启动了包含所有四大服务的完整 RVP 5.x 环境。一个功能齐全的平台固然强大，但在真实的软件工程实践中，我们更应遵循 “奥卡姆剃刀原则”——如无必要，勿增实体。值得注意的是，当前框架已将流程引擎升级为国产的 WarmFlow，虽然它比原先的 Flowable 更为轻量，但并非所有项目都需要它。本节将深入探讨，在项目初期，为什么“做减法”会为我们带来显著的收益。

3.1.1. 移除的核心理由

对于暂时不需要工作流功能或流程需求极为简单的项目而言，保留 ruoyi-workflow 模块（其核心为 WarmFlow 引擎）会引入三个不必要的“负担”：

  1. 拖慢启动速度：任何工作流引擎在 Spring Boot 启动时，都需要进行一系列初始化操作，WarmFlow 也不例外。它需要加载流程定义、检查数据表结构、初始化相关服务 Bean，这会增加 ruoyi-admin 服务的启动时间，影响日常的开发调试效率。
  2. 增加维护复杂性：每引入一个模块，就意味着增加了一个潜在的故障点和维护维度。当您未来升级主框架时，还必须同步考虑 WarmFlow 引擎的版本兼容性问题。对于用不上该功能的团队来说，这无疑增加了额外的认知负担和技术债务。
  3. 占用系统资源：WarmFlow 会在数据库中创建一套以 wf_... 为前缀的数据表。在运行时，它也会作为一个常驻服务，持续占用一定的内存和 CPU 资源。移除它，能让我们的数据库结构和应用服务器都变得更加“清爽”和高效。

最关键的是，从本系列笔记的学习路径来看，工作流是计划在最后阶段讲解的高级主题，在此之前的所有章节内容均不依赖它。因此，在学习初期移除它，可以让我们更专注于核心功能的学习，这并非意味着彻底放弃工作流，而是一种循序渐进的策略。

3.1.2. 了解我们移除的对象：WarmFlow 与 BPMN

在动手移除之前，我们必须清晰地理解它的本质，以确保我们的决策是明智的。

  • WarmFlow：这是一款国产、轻量级且高性能的 业务流程引擎（Business Process Engine）。它的核心使命是负责解析、执行和管理业务流程的生命周期。它是框架当前版本中流程功能的核心。
  • BPMN (Business Process Model and Notation)：这是一种全球公认的、标准化的 图形化语言，专门用于“绘制”业务流程图。它提供了一套统一的符号和规范，使得业务人员、产品经理和开发人员能够使用同一种“语言”来描述复杂的业务流程。

它们之间的关系是：业务分析师使用 BPMN 规范绘制出流程图“蓝图”（例如，员工提交 -> 部门经理审批 -> HR 审批 -> 结束），WarmFlow 引擎则能够精确地“解读”这张蓝图（通常是其背后的 XML 文件），并像一个自动化调度中心一样，严格按照图上定义的规则驱动流程实例一步步地流转。

相比于框架早期版本使用的 Flowable，WarmFlow 在 学习成本、设计器集成、性能和本土化支持 上更具优势，这也是框架进行技术选型升级的关键原因。

3.1.3. 决策依据：何时保留，何时移除？

理解了 WarmFlow 的核心价值，我们就能清晰地界定它的适用场景。

如果您的系统具备以下一个或多个特征，那么绝对不应该移除工作流模块：

  1. 复杂且多变的多人审批流程：例如，一个报销流程，金额小于 1000 元由部门经理审批；1000 至 5000 元需增加财务审批；大于 5000 元则需要总经理最终审批。
  2. 业务规则需要频繁调整：例如，公司的采购流程可能因组织架构调整而随时增减审批节点或变更审批人。使用 WarmFlow，业务人员可以直接在图形界面上“拖拽”修改流程，而无需开发人员修改一行 if-else 代码。
  3. 需要对流程状态进行可视化追踪：需要让用户能清晰地看到“当前单据”流转到了哪一步、由谁处理、历史记录是什么。

反之，如果您的项目只是以下类型，那么 WarmFlow 就属于“大材小用”：

  • 一个简单的信息管理系统（以 CRUD 为主）。
  • 审批流程极其固定且简单（例如，文章发布只有“编辑 -> 审核通过”两个固定步骤）。
  • 系统压根没有任何审批功能。

在这些场景下，移除工作流是毫无疑问的最佳选择。

3.1.4. 本章小结

通过本章的讨论，我们为后续的操作奠定了坚实的理论基础，明确了移除工作流模块的动机和决策依据：

  • 移除的理由：为了提升开发效率、降低维护复杂度和减少系统资源占用，从而构建一个更精简、更高效的开发起点。
  • WarmFlow 的本质：它是一个能执行 BPMN 标准流程图的、轻量级的国产 Java 引擎，也是当前框架的流程核心。
  • 决策的黄金法则：当且仅当系统面临“复杂、多变、需可视化”的审批流程时，才需要保留它。对于其他所有情况，果断移除。

3.2. 模块与文件移除（物理层）

在 3.1 节中，我们已经充分讨论并明确了在特定场景下“瘦身”工作流模块的价值。理论探讨结束，现在我们正式进入实战操作，打响架构瘦身的第一枪。本节我们将从“物理层面”入手，学习如何从 IntelliJ IDEA 中移除 ruoyi-workflow 模块，并彻底删除它占用的物理文件。

3.2.1. 定位 ruoyi-workflow 模块

首先，请在 IDEA 的项目视图（Project View）中，展开我们的后端项目 RuoYi-Vue-Plus。

我们要找的 ruoyi-workflow 模块并不在根目录，而是被聚合在了 ruoyi-models（业务模块）这个父模块下。

文件路径：RuoYi-Vue-Plus/ruoyi-models/ruoyi-workflow

3.2.2. 步骤一：在 IDEA 中移除模块 (Remove Module)

我们的第一步是告诉 IDEA：“这个目录不再是一个需要你管理的模块了”。

  1. 在项目视图中，找到 ruoyi-workflow 模块。
  2. 选中该模块，点击鼠标右键，在弹出的菜单中选择 Remove Module...（移除模块）。
  3. 此时会弹出一个确认对话框，询问你是否要从项目中移除 ruoyi-workflow 模块。我们点击 Remove（移除）按钮。

image-20251106155213261

执行此操作后：ruoyi-workflow 目录的图标会从“模块”图标（蓝色小方块）变成一个普通的“文件夹”图标，并且通常会变成灰色，表示它已不属于当前的项目结构。

3.2.3. 步骤二：从硬盘删除物理文件 (Delete)

在上一步，我们只是解除了 IDEA 对该模块的“引用”，但代码文件本身还静静地躺在我们的硬盘上。接下来，我们要进行物理删除。

  1. 再次选中刚刚变成灰色文件夹的 ruoyi-workflow 目录。
  2. 点击鼠标右键，这次我们选择 Delete...（删除）。
  3. IDEA 会弹出确认框，警告此操作将从硬盘上永久删除文件。我们确认无误后，点击 Delete 按钮。

至此，ruoyi-workflow 模块相关的几十个 Java 类和配置文件就从我们的项目中彻底消失了。

3.2.4. 本节小结

我们完成了物理层面的清理工作：

  • 分离引用：使用 IDEA 的 Remove Module 功能，将 ruoyi-workflow 从项目结构中分离。
  • 彻底删除：使用 Delete 操作，将模块的物理文件从硬盘上清除。

注意：此时我们的项目处于一个 “严重损坏” 的状态。虽然物理文件被删了，但项目的“户口本”（pom.xml 文件）上还写着它的名字。下一步，我们将去修改 pom.xml，解决 Maven 构建时的“找不到模块”错误。

3.3. Maven 依赖清理（逻辑层）

在上一节中，我们已经从 IDEA 和硬盘中 物理删除 了 ruoyi-workflow 模块的所有文件。但此时，我们的项目处于一个“损坏”状态，如果你尝试构建（Build），Maven 会立刻报错。这是因为项目的“户口本”（pom.xml 文件）上还写着 ruoyi-workflow 的名字，Maven 依然尝试去引用这个不存在的模块。

本节我们的核心任务就是在“逻辑层面”彻底清理这些 Maven 依赖关系，让项目重新变得完整。

3.3.1. 清理 ruoyi-models 模块声明

为什么需要它？
ruoyi-models 是一个父模块，它负责“聚合”（Aggregate）所有的业务模块（如 ruoyi-system, ruoyi-demo 等）。它的 pom.xml 文件中有一份清晰的“子模块清单”。我们必须从这份清单中移除 ruoyi-workflow。

如何操作？
我们打开 ruoyi-models 模块的 pom.xml 文件。

文件路径：RuoYi-Vue-Plus/ruoyi-models/pom.xml

在 <modules> 标签内，找到并删除 ruoyi-workflow 的模块声明：

1
2
3
4
5
6
7
8
9
10
11
<project ...>
    <artifactId>ruoyi-models</artifactId>
    <packaging>pom</packaging> <modules>
        <module>ruoyi-system</module>
        <module>ruoyi-generator</module>
        <module>ruoyi-job</module>
        <module>ruoyi-demo</module>
        <module>ruoyi-workflow</module>
    </modules>
    
</project>
  • 核心要点：此步骤是告诉 ruoyi-models 这个父模块，它不再管理 ruoyi-workflow 这个子模块。

3.3.2. 清理 ruoyi-admin 依赖引入

为什么需要它？
ruoyi-admin 是我们的主启动模块，它需要“依赖”（Depend on）并使用各个业务模块的功能。因此，它的 pom.xml 里声明了对 ruoyi-workflow 的依赖。我们必须切断这个依赖。

如何操作？
接着，我们打开 ruoyi-admin 模块的 pom.xml 文件。

文件路径：RuoYi-Vue-Plus/ruoyi-admin/pom.xml

在 <dependencies> 标签内，找到并删除 ruoyi-workflow 的依赖项：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<dependencies>
    <dependency>
        <groupId>org.dromara</groupId>
        <artifactId>ruoyi-common-log</artifactId>
    </dependency>

    <dependency>
        <groupId>org.dromara</groupId>
        <artifactId>ruoyi-workflow</artifactId>
    </dependency>
    
    <dependency>
        <groupId>org.dromara</groupId>
        <artifactId>ruoyi-demo</artifactId>
    </dependency>

    </dependencies>
  • 核心要点：此步骤是告诉 ruoyi-admin 启动模块，它不再需要 ruoyi-workflow 提供的任何类或功能。

3.3.3. 清理根 pom.xml 版本声明

为什么需要它？
项目的根 pom.xml 文件（即最外层的 pom.xml）使用 <properties> 标签来统一管理所有模块的“版本号”，这是一个最佳实践。ruoyi-workflow 的版本号也在这里定义。虽然在某些情况下，不删除它项目也能运行，但从“代码洁癖”和“配置规范性”角度出发，我们必须将其清理干净，避免留下一个无用的配置项。

如何操作？
最后，我们打开项目 根目录 下的 pom.xml 文件。

文件路径：RuoYi-Vue-Plus/pom.xml

在 <properties> 标签内，找到并删除 ruoyi-workflow.version 的版本属性声明：

1
2
3
4
5
6
7
8
<properties>
    <ruoyi-job.version>5.1.0</ruoyi-job.version>
    <ruoyi-demo.version>5.1.0</ruoyi-demo.version>

    <ruoyi-workflow.version>5.1.0</ruoyi-workflow.version>

    <spring-boot.version>3.1.5</spring-boot.version>
    </properties>
  • 核心要点：此步骤是为了保持版本属性的干净，移除冗余配置。

3.3.4. 刷新 Maven 依赖

在我们完成了对三个 pom.xml 文件的修改后，必须告知 IDEA 重新加载 Maven 配置，使其“感知”到项目的结构变化。

  1. 点击 IDEA 右侧的 Maven 侧边栏。
  2. 点击左上角的“刷新”按钮（Reload All Maven Projects）。

IDEA 会重新分析依赖关系。操作完成后，所有 pom.xml 文件中关于 workflow 的错误提示（如果有的话）都会消失，我们的项目在“逻辑层面”也完成了瘦身。

3.3.5. 本节小结

我们完成了逻辑层面的清理，让 Maven 配置与物理文件保持一致：

  • 清理 ruoyi-models/pom.xml：移除了 <module> 声明，解除了父子模块关系。
  • 清理 ruoyi-admin/pom.xml：移除了 <dependency> 依赖，切断了主应用对模块的引用。
  • 清理根 pom.xml：移除了 <properties> 中的版本号，消除了冗余配置。
  • 刷新 Maven：最后一步必须执行 Reload All Maven Projects 使配置生效。

3.4. 移除 YML 配置（配置层）

在 3.3 节中，我们已经彻底清理了三个核心 pom.xml 文件，让 Maven 在“逻辑层面”彻底忘记了 ruoyi-workflow 模块。我们的代码依赖关系现在是干净的。

然而，仅仅移除代码依赖还不够。ruoyi-admin 作为主启动模块，它在配置文件中依然保留着 ruoyi-workflow 模块所使用的 warm-flow 工作流引擎的初始化配置。如果我们现在启动项目，Spring Boot 会尝试根据这些 YML 配置去初始化 warm-flow 相关的 Bean，但由于我们已经删除了 JAR 包依赖，它会因为找不到对应的类（ClassNotFoundException）而导致启动失败。

本节，我们就将完成配置层的“瘦身”，删除这些残留的配置项。

3.4.1. 定位 application-dev.yml

首先，我们打开 ruoyi-admin 模块，找到开发环境的核心配置文件。

文件路径：RuoYi-Vue-Plus/ruoyi-admin/src/main/resources/application-dev.yml

注意：我们修改的是 application-dev.yml（开发环境），如果您后续需要打包生产环境，也应检查并清理 application-prod.yml（生产环境）中的相应配置。

3.4.2. 删除 warm-flow 配置块

打开 application.yml 文件，拉到 文件最底部。根据我们项目的实际源码，您会看到 warm-flow 的相关配置块：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# ... (上方其他配置)

--- # warm-flow工作流配置
warm-flow:
  # 是否开启工作流，默认true
  enabled: true
  # 是否开启设计器ui
  ui: true
  # 是否显示流程图顶部文字
  top-text-show: true
  # 是否渲染节点悬浮提示，默认true
  node-tooltip: true
  # 默认Authorization，如果有多个token，用逗号分隔
  token-name: ${sa-token.token-name},clientid

如何操作？
我们的任务非常简单：将整个 warm-flow 根配置块，从 --- # warm-flow工作流配置 注释开始，到 token-name:... 结束，全部选中并删除。

删除后，保存 application-dev.yml 文件。

至此，ruoyi-admin 模块的代码和配置中，所有关于工作流的痕迹都已被清除干净。Spring Boot 在启动时将不再读取任何关于 warm-flow 的配置。

3.4.3. 本节小结

我们完成了配置层的清理工作，确保了 Spring Boot 启动时不会因缺少依赖而失败：

  • 定位配置文件：我们锁定了主启动模块 ruoyi-admin 下的 application-dev.yml。
  • 纠正目标：明确了我们移除的是 warm-flow 配置，而非其他工作流引擎。
  • 删除冗余配置：完整删除了文件末尾的 warm-flow: 配置块，避免了启动时因 ClassNotFoundException 引发的崩溃。

3.5. 清理数据库表（数据层）

在 3.4 节中，我们已经将 application-dev.yml 配置文件清理干净。至此，我们的 应用程序代码（物理、逻辑、配置层）已经完全“忘记”了工作流模块。如果现在启动，项目在代码层面将不再报错。

然而，我们的“瘦身”工作还差最后一步。回想在 2.3 节中，我们初始化数据库时，导入了 ry_workflow.sql 脚本。这个脚本在我们的 ruoyi-vue 数据库中创建了 warm-flow 引擎专属的数据表。

本节，我们将作为“数据库管理员”（DBA），完成最后的“数据层”清理工作，让数据库也变得干净。

3.5.1. 识别工作流数据表

warm-flow 引擎及其 RVP 扩展在数据库中创建的表具有非常高辨识度的 前缀：

  1. flw_...：(FLoW) 这是 warm-flow 引擎自身使用的核心表以及 RVP 的扩展表。例如 flw_category（流程分类）、flw_definition（流程定义）、flw_instance（流程实例）、flw_task（流程任务）等。
  2. test_leave：这是 ruoyi-workflow 模块自带的“请假流程”演示业务表。

我们的目标就是删除所有以此为前缀的表。

关键警告：请勿误删 sj_ 开头的表！在清理时，您会看到 sj_...（SnailJob）的表。这些是 任务调度中心 的表，不是工作流的表，我们必须保留它们。只删除 flw_ 和 test_leave 表。

3.5.2. 在 Navicat 中批量删除

请打开您的 Navicat 数据库管理工具，并连接到 ruoyi-vue 数据库。

  1. 在左侧的表列表中，点击“名称”列进行排序，让所有表按字母顺序排列。
  2. 向下滚动，找到所有以 flw_ 开头的表。
  3. 选中第一个 flw_... 表（例如 flw_category）。
  4. 按住 Shift 键。
  5. 继续向下滚动，选中最后一个 flw_... 表（例如 flw_task_his）。
  6. （可选）如果 test_leave 表存在，也请一并选中它。
  7. 在选中的表上点击鼠标右键，选择“删除表…”。
  8. Navicat 会弹出确认框，询问是否永久删除这些表。点击“删除”或“确定”。

片刻之后，数据库就完成了数据层的瘦身。

3.5.3. 本节小结

我们完成了架构瘦身的最后一步：数据层清理。

  • 识别目标：根据 ruoyi-workflow 模块的源码，锁定了 flw_ 前缀的表和 test_leave 演示表。
  • 批量删除：使用 Navicat 配合 Shift 键批量选中并删除了所有目标表。
  • 关键警告：再次强调，sj_ (SnailJob) 表必须保留，不能误删。

3.6. 重启服务与验证

在完成了从 3.2 节到 3.5 节的四大清理步骤（物理文件、Maven 逻辑、YML 配置、数据库表）之后，我们的 RuoYi-Vue-Plus 项目已经从一个“全功能版”被我们精简为了“轻量版”。

理论上，所有的“手术”都已完成。本节，我们将作为“测试工程师”，对“手术”结果进行最终的验收——重启服务，验证我们的瘦身成果。

3.6.1. 重启 DromaraApplication

我们的目标非常明确：确认 ruoyi-admin 主服务在移除了工作流模块后，能够无错误地成功启动。

  1. 在 IntelliJ IDEA 中，找到我们的主启动类。
    文件路径：RuoYi-Vue-Plus/ruoyi-admin/src/main/java/org/dromara/DromaraApplication.java
  2. 点击 DromaraApplication 类旁边的“运行”或“调试”按钮，选择“重新运行 ‘DromaraApplication’”（Rerun）。

3.6.2. 观察启动日志与速度

现在，请集中注意力到 IDEA 的“Run”或“Debug”控制台窗口，我们需要观察以下几个关键点：

  1. 观察启动速度：您应该会直观地感觉到，本次启动速度 明显快于 第二章时的首次启动。因为 Spring Boot 不再需要加载和初始化 warm-flow 引擎的组件。
  2. 观察 warm-flow 日志：在第二章启动时，控制台可能会打印包含 warm-flow 关键字的日志。这一次，这些日志应该 完全消失 了。
  3. 观察 Error 日志：检查控制台，确保没有抛出任何与 workflow、warm-flow、ClassNotFoundException 或 BeanCreationException 相关的红色错误信息。
  4. 观察最终结果：当控制台平稳输出 Spring Boot 的 Logo，并最后打印出 Started DromaraApplication in X.XXX seconds 时，即代表我们的架构瘦身实战——圆满成功！

3.6.3. 本节小结

我们完成了本章的最终验证工作：

  • 重启服务：通过重启 DromaraApplication 主服务来检验我们的瘦身成果。
  • 验证结果：通过观察控制台日志，确认 warm-flow 相关组件已不再加载，并且服务能够无错误、更快速地成功启动。