7天学会SpringBoot+Vue3企业级项目RuoyiOffice（一）：架构篇——一个底座，多端通达

🌐 文档地址：https://ruoyioffice.com
 👇 文章底部获取源码和演示地址 👇
 💬 ：17156169080（获取产品咨询）

这是《7天学会SpringBoot+Vue3企业级项目RuoyiOffice》系列第 1 篇。七天不会让人凭空获得多年企业项目经验，但可以用一套真实的平台源码，建立从启动、后端、前端、权限、流程到上线交付的完整认知。第一天先看全局：为什么企业系统需要一个统一底座？PC Web、移动 APP、微信小程序和企业协同入口，怎样共享同一套业务能力？

▲ 本篇核心视觉：终端层负责接入，业务应用层承载企业场景，智能与物联层提供增强能力，平台能力层负责统一治理。四层共同组成 RuoYi Office 的产品架构。

一、先看产品：同一个平台，PC 与移动端各有入口

架构篇不先从一张业务单据开始，而是先看用户真正接触到的产品入口。RuoYi Office 的 PC 工作台面向日常管理和复杂配置，UniApp 移动端面向移动办公、待办处理和现场协同；两端外观和交互不同，但背后连接的是同一个组织、权限、流程和业务平台。

▲ PC 工作台首页：工作台、应用中心、我的单据、通知公告和日程待办被组织在同一屏，体现的是企业平台入口，而不是某个单独业务模块。

▲ 移动端首页：待办、邮箱、考勤、业务申请、请假销假和企业云盘被组织成移动工作入口，不把 PC 页面简单缩小。

从这两个入口，可以先得到三个产品层面的判断：

二、企业为什么需要“一个底座”

很多系统早期都可以从一个后台、几张表和一组 CRUD 开始。但进入真实企业环境后，系统会同时面对多端入口、多业务域、复杂组织、审批流转和不同部署方式。

如果每个端各写一套接口，每个业务模块各自实现登录、权限、文件和消息，项目短期可以快速增加功能，长期却会出现接口不一致、权限口径不一致和维护成本不断上升的问题。

“一个底座，多端通达”不是一句宣传语，而是一种工程约束：业务规则集中，终端体验可以不同；平台能力统一，业务模块保持边界。

三、RuoYi Office 的四层产品架构

RuoYi Office 可以用四层来理解：终端层、业务应用层、智能与物联层、平台能力层。

箭头表示依赖方向，不代表所有请求都必须逐层同步调用。平台能力层为上层提供公共服务，智能能力可以被业务模块按需调用，终端则通过各自 API 和页面承载用户操作。

3.1 终端层：入口可以不同，业务不能失控

PC Web 端是复杂企业后台的主要工作入口，当前主应用位于 ruoyi-office-vben/apps/web-antd，技术栈包括 Vue 3、TypeScript、Vben Admin、Ant Design Vue、VxeTable 和 Vite。

移动端位于 ruoyi-office-uniapp，使用 UniApp + Vue 3 + unibest，目标覆盖 H5、微信小程序和 App。移动端更适合待办审批、消息提醒、扫码、拍照上传和移动打卡等高频动作。

两端应共享 API 契约、业务状态和流程契约，而不必强行共享布局密度和交互方式：

3.2 业务应用层：按业务域拆分，而不是按页面堆叠

企业平台的业务应用层通常包含协同办公、人力资源、营销销售、经营管理和数字渠道等业务域。RuoYi Office 当前目录中可以看到 system、infra、bpm、oa、hrm、asset、contract、project、crm、erp、mall、ai、iot、report 等模块。

业务模块的边界有三个判断标准：

1. 模块拥有相对完整的业务对象和状态模型。
2. 模块可以通过 API 或公共能力与其他模块协作。
3. 模块内部的 Controller、Service、Mapper、DO 和 VO 由本模块负责。

后端通常采用 xxx-api 和 xxx-server 的二级结构。xxx-api 放跨模块使用的 DTO、枚举和接口契约，xxx-server 放 Controller、Service、Mapper 和具体实现。

3.3 智能与物联层：增强业务，不替代业务边界

AI 对话、AI 写作、知识库、RAG、AI 工作流和 IoT 是平台的增强能力。它们可以帮助企业完成知识问答、内容生成、文档检索、设备告警和自动化编排，但不能绕过业务模块直接修改核心业务数据。

AI 可以辅助生成合同初稿，也可以从制度文档中找到报销规则；但合同的审批、版本、签署状态和归档结果，仍然应该由合同业务模块和流程模块负责。IoT 设备可以上报温度、门禁或生产状态，但设备数据进入资产、项目或经营分析前，仍需要明确的数据模型和业务归属。

智能能力负责理解、辅助和编排，业务模块负责事实、状态和责任。

3.4 平台能力层：把公共能力沉淀为底座

平台能力层是“一个底座”的核心。它承载跨业务域复用的规则和基础设施：

如果这些能力散落在每个模块里，系统会逐渐形成“OA 一套权限、CRM 另一套权限、移动端再一套判断”的重复实现。平台化的目标，就是让业务模块专注于业务，而不是重复建造基础设施。

四、技术架构：从三端同源到平台底座

产品架构回答“系统服务哪些场景”，技术架构回答“这些能力由哪些工程层承载”。RuoYi Office 的技术栈可以概括为：Vue 3 / UniApp 负责多端体验，Spring Boot 3.5 负责业务服务，Spring Security、OAuth2、多租户和数据权限负责安全边界，MyBatis-Plus、Redis、消息队列和任务调度负责数据与异步能力。

▲ 技术架构全景：前端层、网关与安全层、Spring Boot 服务层、数据与中间件层、业务模块层共同组成平台。业务能力按需启用，底座能力集中复用。

4.1 前端层：三端同源，不等于三端同页

三端共享后端 API、登录体系、业务状态和权限规则；页面布局、交互密度和设备能力则由各端独立适配。

4.2 网关与安全层：所有请求先建立可信上下文

在微服务模式下，客户端请求通常经过 Nginx 或 Spring Cloud Gateway，再路由到具体业务服务。安全层负责 Token 校验、用户类型识别、租户上下文、权限判断和限流等横切能力。

在单体模式下，网关可以不参与本地调用，但认证、权限、租户和业务模块边界仍然存在。因此，单体不是“没有架构”，而是把多个服务运行在同一个应用进程中。

4.3 服务层：Spring Boot 承载业务与平台能力

后端以 Java 17 和 Spring Boot 3.5 为基础，按 xxx-api 和 xxx-server 拆分业务模块。System、Infra、BPM、OA、HRM、CRM、ERP、Asset、Contract、Project、AI、IoT 等模块各自维护领域逻辑，通过公共 Starter 和模块 API 协作。

4.4 数据与中间件层：把同步、异步和持久化分开

MySQL 保存业务事实，Redis 负责缓存、分布式锁和高频状态，RocketMQ 用于异步事件和跨服务解耦，XXL-Job 负责定时调度，MinIO 或 OSS 负责文件和附件。不同组件职责不同，不能把“所有数据都放 Redis”或“所有操作都同步调用”当作通用方案。

五、部署架构：同一套能力适配不同交付形态

企业项目最终要面对的不是一台开发电脑，而是客户服务器、云主机、容器平台、反向代理、数据库、对象存储和监控体系。RuoYi Office 的部署架构需要同时支持单体部署和微服务部署，因此部署图要把“请求入口、业务服务、中间件、运维工具”分开看。

▲ 典型部署拓扑：客户端经过 HTTPS、Nginx 或云负载均衡进入网关，再路由到业务服务；数据库、缓存、消息、对象存储和监控服务位于后端基础设施区。

单体模式可以把业务服务和部分平台能力装配到 yudao-server 中，适合本地学习和中小规模交付；微服务模式再引入 Gateway、Nacos 和独立服务部署，适合按模块扩容和多团队协作。两种模式共享业务模块和平台设计，不应该维护两套业务逻辑。

六、从一条请求看清技术架构

架构图解决“有哪些层”，一条请求解决“这些层如何协作”。以用户打开一个业务详情为例：

这条链路可以拆成四个问题：请求来自谁、数据属于谁、业务如何执行、流程和附件如何协作。它们分别对应身份上下文、租户与数据权限、业务 Service、BPM/文件/消息等平台能力。

6.1 后端分层：Controller 不负责所有事情

Controller 接收参数、校验权限、调用 Service 和返回统一结果；Service 负责业务规则、事务编排和跨模块协作；Mapper 负责数据访问；DO 负责数据库映射；VO 负责 API 输入输出。

@RestController@RequestMapping("/oa/car-apply-bill")@Validatedpublic class CarApplyBillController {    @Resource    private CarApplyBillService carApplyBillService;    @PostMapping("/submit")    @PreAuthorize("@ss.hasPermission('oa:car-apply-bill:create')")    public CommonResult<Long> submitCarApplyBill(            @Valid @RequestBody CarApplyBillSaveReqVO reqVO) {        return success(carApplyBillService.submitCarApplyBill(reqVO));    }    @GetMapping("/page")    public CommonResult<PageResult<CarApplyBillRespVO>> getPage(            @Valid CarApplyBillPageReqVO pageReqVO) {        PageResult<CarApplyBillDO> result =                carApplyBillService.getCarApplyBillPage(pageReqVO);        return success(BeanUtils.toBean(result, CarApplyBillRespVO.class));    }}

重点不是接口名称，而是层次关系：权限在接口边界检查，业务规则进入 Service，Controller 不直接拼 SQL，也不直接修改流程表。

6.2 前端工程：页面、API 和公共组件各司其职

PC 页面通常拆为 list、info、data.ts 和 api。列表关注查询条件、表格列和操作入口；详情关注字段、校验、附件和状态；API 文件集中维护请求函数和类型。

export function getCarApplyBill(id: number) {  return requestClient.get<CarApplyBillApi.CarApplyBill>(    `/oa/car-apply-bill/get?id=${id}`,  );}export function submitCarApplyBill(data: CarApplyBillApi.CarApplyBill) {  return requestClient.post('/oa/car-apply-bill/submit', data);}

移动端可以复用同一业务 API，但页面应按移动场景重新组织。移动端 OA API 位于 ruoyi-office-uniapp/src/api/oa/car，业务页面放在 OA 业务分包，BPM 公共页面只负责流程详情和审批能力。

七、模块化单体与微服务：运行方式不同，边界不应不同

RuoYi Office 同时支持单体和微服务部署。单体模式适合学习、快速开发和中小规模交付；微服务模式适合服务独立部署、团队边界清晰和需要独立扩容的场景。

一个常见误区是把“微服务”当成企业级的唯一答案。真正重要的是模块边界、数据边界和平台能力边界。只要边界设计正确，单体可以演进到微服务；如果边界混乱，拆成多个服务只会把混乱变成网络调用。

八、用一个真实业务验证四层架构

为了验证四层架构，可以把一个用车申请放回产品中观察，但它只是案例，不是本文主角。

用户在 PC 端填写申请，终端层负责页面交互；OA 模块负责单据和车辆规则；BPM 负责审批；平台能力负责认证、权限、附件和消息；审批完成后，业务模块把流程结果转换成“待还车”等业务状态。

▲ 真实系统截图：流程设计器解决节点、审批人和路径配置；它不替代业务模块保存业务字段或维护业务状态。

▲ 真实系统截图：业务详情页面展示单据字段、流程状态和后续业务动作，说明流程结果已经回到业务上下文。

这个例子说明了平台架构中的一个关键原则：流程是业务流转能力，不是业务数据的最终归属。

九、从源码目录建立全局导航

第一次打开大型企业项目，最容易陷入“文件太多，不知道从哪里看”。建议按四条线索建立导航。

9.1 先看启动线

从 ruoyi-office/yudao-server 开始，确认单体启动入口、Profile 和模块聚合关系；再看 yudao-gateway，理解微服务模式下的入口和路由。

9.2 再看平台线

从 yudao-framework 开始，重点关注 security、tenant、mybatis、web、redis、rpc、mq 和 file 等公共 Starter。

9.3 然后看业务线

选择一个业务模块，例如 yudao-module-oa，沿着 controller → service → dal → convert → vo 阅读。不要一开始从数据库表或某个工具类切入，先找到一个用户动作，再向下追踪。

9.4 最后看端侧线

PC 端从 apps/web-antd/src/views 和 src/api 看页面与接口；移动端从 src/pages-* 和 src/api 看业务分包和请求层；BPM 详情则进一步检查业务表单如何嵌入审批页面。

十、七天系列学习路线

十一、第一天的学习结果

看完架构篇，建议先完成四项检查：

1. 能说清终端层、业务应用层、智能与物联层、平台能力层分别负责什么。
2. 能在源码中找到单体启动入口、后端业务模块、PC 主应用和 UniApp 主目录。
3. 能解释为什么权限、租户、流程、文件和消息应该沉淀为平台能力。
4. 能用一条请求说明“登录用户如何进入业务模块，业务结果如何回到流程和消息体系”。

完成这四项，才算真正建立项目地图。成功打开首页，只能证明环境具备启动条件，不能证明已经理解企业级架构。

常见问题（FAQ）

RuoYi Office 的核心架构是什么？

RuoYi Office 采用前后端分离、多端协同和模块化业务架构，可以按终端层、业务应用层、智能与物联层、平台能力层理解；后端同时支持单体和微服务运行方式。

Spring Boot 3、Vue 3 和 UniApp 分别负责什么？

Spring Boot 3 负责后端应用和业务服务，Vue 3 负责 PC 管理端，UniApp + unibest 负责移动端多端发布。三者通过统一 API、业务状态和流程契约协同。

为什么企业项目不能只做一个 PC 管理后台？

PC 适合复杂管理和配置，但审批、消息、扫码、拍照和现场操作通常发生在移动端。企业平台需要多个入口，同时保持同一套业务规则和数据事实。

单体模式是不是不够企业级？

不是。单体和微服务主要是两种部署与运行方式，企业级的关键仍然是模块边界、权限边界、数据边界和可运维性。单体适合先验证业务，再按实际规模演进。

AI 和 IoT 是否会替代传统业务模块？

不会。AI 和 IoT 可以提供理解、辅助、采集和自动化能力，但核心业务事实、业务状态、审批结果和责任归属仍应由业务模块维护。

结语

真正可持续的企业级项目，不是把所有技术名词堆在一起，而是让终端、业务、智能能力和平台底座各自承担清晰责任。RuoYi Office 把这些能力组织成一套可以学习、扩展和交付的平台架构：一个底座，多端通达；业务持续增长，底层规则保持稳定。

下一篇进入启动篇：从源码目录、数据库、后端 Profile、前端代理和登录请求开始，把这张架构图真正跑起来。

如果这篇对你有用，点个「在看」或收藏。

🌐 演示地址：https://ruoyioffice.com/web
 📦 GitHub 源码：https://github.com/yuqing2026/ruoyi-office
 📦 Gitee 源码：https://gitee.com/yqzy1688/ruoyi-office
 💬 微信：17156169080（获取产品咨询）

打开演示地址直接查看系统。