// the find
YunaiV/yudao-cloud
ruoyi-vue-pro 全新 Cloud 版本，优化重构所有功能。基于 Spring Cloud Alibaba + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城、CRM、ERP、MES、IM、AI 大模型、IoT 物联网等功能。你的 ⭐️ Star ⭐️，是作者生发的动力！
yudao-cloud is a Spring Cloud Alibaba microservices rebuild of the ruoyi-vue-pro admin platform, bundling RBAC, multi-tenancy, a Flowable workflow engine, payments, and a stack of vertical modules (ERP, CRM, MES, WMS, HRM, OA, mall). It's aimed at Java teams building an internal admin/SaaS backend for the Chinese market who want a batteries-included starting point instead of assembling Nacos/Seata/RocketMQ/Flowable themselves.
The module boundaries are real, not cosmetic: system/infra is required, workflow/payment/report is optional, and ERP/CRM/MES/etc. are opt-in verticals, with a documented migration path to strip down to a 'mini' build. The microservices plumbing is fully wired rather than just namedropped — Nacos for registry/config, Sentinel, Seata for distributed transactions, RocketMQ, and Gateway all integrate end to end, which is usually the part people get wrong when rolling their own. The Flowable workflow module has a proper BPMN designer plus a DingTalk/Feishu-style simple designer, with actual implementations of or-sign, sequential sign, delegation, sub-processes, and timeout auto-actions rather than a toy demo. Database portability is unusually wide, with per-vendor SQL scripts checked in for MySQL, PostgreSQL, Oracle, SQL Server, and several domestic databases (DM, KingBase, openGauss).
Nearly everything — code comments, docs, demo sites — is Chinese-only; the README is translated but the codebase isn't, so non-Chinese-reading teams are working through a translator for anything beyond the surface API. Running the actual microservices stack means standing up Nacos, Sentinel, Seata, RocketMQ, and Gateway before you can do anything, which is a lot of infrastructure for teams that don't need multi-service deployment (the companion monolith, ruoyi-vue-pro, exists for exactly that reason and is the better starting point for most people). The vertical business modules (ERP/CRM/MES/HRM/FMS/PMS/OA) live in the same repo behind module flags rather than as separable packages, so adopting just one of them still means vendoring the entire tree. The claim that everything is unit-tested doesn't hold evenly across the codebase — the older system/infra modules are solid, but coverage thins out noticeably in the newer vertical modules.