LHMS Framework：让新项目复用已有的业务管理能力

每推出一个新产品，团队都需要准备一套后台：谁来管理会员，谁能审核资金申请，运营如何发布内容，客服如何处理用户问题。这些需求在不同项目中反复出现，占用的交付精力也不断累积。

我负责建设的 LHMS Framework，将这部分共性需求沉淀为通用业务中台，并配套 LHMS Admin 管理后台。它后来被复用到 OTC、BT CEX、Simple、SDH 等项目中，成为新产品可以直接继承的业务管理基础。

产品不同，后台却在重复建设

当时各项目独立开发和部署。产品需要有自己的业务特色，但会员维护、内容发布、权限分配等管理工作，大量沿用相似逻辑。

逐个项目建设这些功能，意味着同一类需求需要反复开发和联调，后续修复也要分别维护。我希望把已经解决过的共性问题保留下来，让新项目的交付工作更多围绕自身的核心业务展开。

中台的范围需要控制。把所有产品规则都放进公共平台，会让不同项目互相牵制；只提供登录和权限，又不足以减少实际业务中的重复建设。

我以可复用的管理流程划定范围：会员与代理关系维护、内容运营、资金申请处理、客服工单等进入通用中台；交易品类、订单规则及产品特有流程，由各项目继续扩展。

例如，不同交易产品都需要查询订单、处理充值提现，但订单如何产生、如何结算有各自的规则。因此，共用管理入口与基础能力，同时保留具体业务逻辑的调整空间。各项目继承这些能力后，仍然可以独立部署和迭代。

LHMS Framework 基于 ruoyi-vue-pro 二次开发，采用 JDK 17 与 Spring Boot 3.x，并围绕会员、运营、资金订单及客服等实际场景，整理业务模块与公共能力，为后续多个产品提供可复用的后台基础。

改造过程中，需要梳理原有能力之间的依赖。例如，登录身份同时用于接口鉴权、操作日志，以及业务记录中创建人、修改人的自动填充。调整认证实现时，也需要衔接这些依赖，才能保证后台操作仍然可以追溯到具体人员。

因此，我在扩展业务功能时，保留并衔接了统一的登录上下文、权限校验与审计字段填充机制。新接入的业务模块可以沿用同一套身份识别和操作记录方式，让会员维护、资金审核等管理功能具备一致的权限边界与操作追溯基础，也减少了各项目重复处理这些基础逻辑的工作。

中台与配套后台覆盖以下业务能力，各项目根据产品范围选用和扩展：

功能范围	具体功能与使用场景
会员与代理管理	查询和维护会员资料、调整账号状态、管理邀请关系与代理层级，支持业务人员维护客户及其归属关系。
内容运营与通知	管理公告、新闻、轮播图、广告及多语言内容；维护邮件模板、短信与发送记录，支持日常内容更新和用户触达。
钱包与资金管理	管理钱包、充值提现申请及支付通道；查看申请详情、执行审核并查询记录，支持资金业务的日常处理。
行情与交易管理	管理交易标的、查询报价和 K 线，并提供现货、合约等订单管理能力，供交易项目按自身业务规则使用和扩展。
客户服务	收集用户反馈、开展即时通信、维护快捷回复，以及接入和结束工单，支持客服处理咨询与跟进问题。
运营数据	查看访问趋势、会员与资金相关统计，查询明细及导出业务记录，为业务跟进提供数据入口。
后台管理与权限	管理工作人员账号、角色、菜单、操作权限和数据范围；查询操作日志、管理文件，支持岗位分工与操作追溯。

建设范围同时覆盖了业务后台。配套的 LHMS Admin 在已有开源管理框架基础上扩展，让运营、审核和客服人员能够实际使用这些能力。

以资金申请为例，审核人员可以从待处理记录进入详情，查看会员、金额、通道和状态，再执行通过或驳回；处理记录可供后续查询。内容运营人员可以自行维护公告和轮播图，客服则通过工单接入、处理并结束服务。岗位权限与操作记录为这些日常工作提供边界和追溯依据。

这些流程让项目交付同时覆盖用户侧功能和后台管理，业务团队获得了开展运营所需的操作入口。

LHMS Framework 与 LHMS Admin 形成了可复用的中台及管理后台，并落入多个派生项目。新项目可以继承已有的会员、运营、订单与客服能力，再补充自己的业务流程。

这种交付方式保留了产品独立性，也留下了公共修复需要跨项目同步的维护成本。它在当时解决的具体问题，是让已经交付过的管理能力能够服务下一个项目。