三类模块
平台治理
平台层维护租户、管理员、套餐、菜单、应用授权和系统升级。它决定“谁可以使用什么”，不直接替代租户完成业务操作。
公共业务能力
用户、登录、角色、素材、内容、支付、钱包、消息、存储和渠道配置属于可复用能力。新应用优先复用这些模块，避免重复创建用户表、订单入口或支付回调。
可插拔业务应用
当前代码中包含测算、心理测评、短剧和热点内容等独立业务。每个应用拥有自己的页面、控制器、逻辑和数据模型，同时共享账号、钱包、支付、租户配置及基础前端组件。
源码盘点结论
按“拥有独立模型、租户管理入口、用户 API 与用户页面”四项条件核对后，当前仓库中已形成完整业务边界的就是以下四个应用：suanming、testreport、ve 和 chigua。它们都已经在本专题中建立独立页面，没有发现第五个同等完整但尚未归档的业务应用。
article、channel、decorate、file、notice、pay、recharge、refund、user 和权限相关目录属于平台或租户公共能力；generator 是代码生成工具。它们会被多个业务应用调用，不应为了凑数量再拆成“小项目”。
这些名称看起来像几个“小项目”，但从系统边界看，它们更适合作为同一 SaaS 底座中的业务应用：它们没有独立的账户、支付和租户体系，也不需要各自重复建设后台框架。项目列表只展示 Easy Admin SaaS，具体能力在项目内部展开。
业务应用地图
| 业务应用 | 核心对象 | 典型流程 | 复用的平台能力 |
|---|---|---|---|
| 测算 | 测算产品、输入项、订单、结果、分销佣金与提现 | 选择产品 → 填写资料 → 支付 → 生成结果 → 查看或分享 | 用户、支付、钱包、分销、文件 |
| 心理测评 | 测评项目、题目选项、答卷、维度评分与报告 | 选择量表 → 作答 → 计分 → 生成报告 → 解锁完整内容 | 用户、订单、支付、内容、消息 |
| 短剧 | 分类、剧目、分集、媒体资源、观看记录与权益订单 | 剧目上架 → 分集发布 → 用户购买 → 校验权益 → 播放与记录 | 用户、支付、对象存储、VOD |
| 吃瓜热点 | 文章、阅读记录、用户状态、解锁订单与运营统计 | 编辑审核 → 发布 → 浏览或解锁 → 阅读 → 收藏与统计 | 用户、支付、内容、域名配置、存储 |
flowchart LR Admin[租户运营后台] --> SM[测算
suanming] Admin --> TR[心理测评
testreport] Admin --> VE[短剧
ve] Admin --> CG[吃瓜热点
chigua] User[PC / H5 / 小程序] --> SM User --> TR User --> VE User --> CG SM --> Shared[用户 / 支付 / 钱包
存储 / 租户配置] TR --> Shared VE --> Shared CG --> Shared
测算
测算应用的重点不是计算公式本身，而是把一次结果生成组织成可追踪的业务流程。产品定义输入项和价格，订单固定用户当时购买的版本，计算任务保存输入快照和执行状态，结果报告只引用本次任务的输出。
测算规则升级后不能直接覆盖历史结果。规则应带版本号，订单记录使用的规则版本；任务失败可以按同一业务号重试，但不能重复扣款或重复结算分销收益。
源码对应 suanming 领域，包含产品目录、测算引擎、订单、两级分销、佣金和提现。完整结构见测算应用架构。
心理测评
心理测评与普通问卷的区别在于量表、计分和解释规则需要保持一致。题目、选项权重、维度区间和报告模板应作为一个可发布版本管理，已经开始作答的用户继续使用原版本。
答卷保存原始选择，评分结果保存各维度得分和所用规则版本。付费只控制完整报告的访问权限，不应影响答案和基础得分的留存。心理测评结果属于敏感数据，后台默认脱敏，并限制导出和批量查看权限。
源码对应 testreport 领域，测评引擎支持题目分支、维度累计和不同评分回调。完整结构见心理测评应用架构。
短剧
短剧应用需要区分业务内容与媒体资源。剧目和分集描述“用户看到什么”，上传文件、转码任务和播放地址描述“媒体怎样交付”。支付成功后发放的是剧目、分集或会员权益，不是一个永久播放 URL。
媒体回调可能重复或乱序，按远端任务号幂等更新。播放时再根据用户权益签发短期地址；观看进度可以异步写入，不能因为统计失败阻塞播放主流程。
源码对应 ve 领域，已经区分剧目、分集、发现流、追剧记录和解锁订单。完整结构见短剧应用架构。
吃瓜热点
热点内容从外部来源进入时先保存来源、抓取时间、原始地址和内容指纹，再进入待审核状态。去重、清洗和人工编辑完成后才生成正式文章，避免采集任务直接修改线上内容。
公开内容、会员内容和下架内容使用明确状态表达。域名或分享链接只是访问入口，文章 ID、会员权益和订单事实仍由服务端判断，不能依赖前端 URL 决定访问权限。
源码对应 chigua 领域，包含文章运营、阅读进度、点赞收藏、付费解锁和订单统计。完整结构见吃瓜热点应用架构。
业务应用的共同边界
- 每个应用维护自己的领域表、状态机和管理页面；
- 登录、支付、钱包、存储和消息通过公共服务调用，不复制实现；
- 通用订单保存支付事实，业务订单保存购买内容和交付状态；
- 应用之间不直接修改对方数据，需要协作时使用服务接口或业务事件；
- 只有当某个应用需要独立团队、独立发布、独立扩容或合规隔离时，才升级为顶层项目。
多租户隔离
共享数据库模式下，业务表通过 tenant_id 标识归属。隔离必须同时存在于四个位置：
- 请求入口识别当前租户。
- 鉴权缓存携带租户和用户上下文。
- 模型查询自动附加租户条件。
- 写入时由服务端确定租户，不能信任前端任意传值。
仅在表中增加 tenant_id 并不等于完成隔离。列表、统计、导出、关联查询和后台任务都必须使用同一租户规则，否则最容易在非主流程中发生越界。
新业务接入检查
| 检查项 | 需要确认的内容 |
|---|---|
| 身份 | 使用平台管理员、租户管理员还是最终用户 |
| 数据 | 哪些表属于租户，哪些配置属于平台 |
| 权限 | 菜单权限、按钮权限和数据范围是否完整 |
| 交易 | 是否复用统一订单、钱包、支付与退款流程 |
| 多端 | PC、H5、小程序是否共享同一业务状态 |
| 运维 | 定时任务、回调和队列能否恢复与重试 |
这种结构的价值不是目录更多，而是让业务应用之间保持清晰边界，同时把稳定的底层能力真正复用起来。