系统设计
一期用一个 Spring Boot 应用。账号、资料、撮合、订单、媒体、消息和会员各自负责自己的数据与规则，跨模块调用明确的业务方法。先不拆微服务，也不单独建管理员服务。
已确定和建议采用的选择
- PostgreSQL 保存业务事实；Redis 存验证码、会话、限流和可重建缓存。
- 图片及资质文件用阿里云 OSS；作品视频用阿里云 VOD。
- PG、Redis 和业务应用一期可以同机部署，之后按流量、维护和故障隔离需要迁移。
- 后端建议使用 Java 21、Spring Boot、数据库迁移工具和统一格式检查。具体依赖版本由实现仓库锁定。
- 基础消息先存 PG、按游标拉取。有实时性需求后，再给消息模块接长连接或第三方 IM。
前端可以采用跨端方案，接口不依赖 Flutter、React Native 或 UniApp 的某一种。
模块怎么分
| 模块 | 自己负责 | 对外提供 |
|---|---|---|
| identity | 登录、会话、身份、账号状态 | 当前操作者、身份与权限判断 |
| profile | 酒吧、艺人、审核、作品、档期说明 | 可公开资料、审核状态、档期检查 |
| matching | 需求、投递、邀约、洽谈与条件版本 | 建立洽谈、修改条件、双方确认 |
| order | 确认订单、档期占用、完成、取消和争议 | 订单详情、合法的状态变更、事件记录 |
| media | 资源所有者、上传状态、访问授权 | 上传凭证、可用资源、短期访问地址 |
| messaging | 会话、成员、文字消息、未读游标 | 发消息、按游标读消息 |
| membership | 套餐、权益、购买意向、有效期 | 当前权益、发布资格检查 |
| reporting | 需求、合作、取消、服务费等汇总 | 只读看板；不修改业务状态 |
控制器处理输入和 HTTP，业务方法处理规则，Repository 处理数据。账号、场地和艺人 ID 从登录身份与资源归属推导，不能只相信请求体传来的 ID。
模块之间的调用
双方确认时，matching 核对条件版本，order 创建订单并占用档期，整个关键写入在同一个 PG 事务内完成。成功提交后，再提醒双方。消息发送失败不能让一个已成功创建的订单消失。
媒体上传由 media 发授权，profile 只绑定属于当前操作者、用途正确且已可用的资源。会员模块只回答有没有某项权益，不改撮合或订单数据。
审核和违规下架放在所属模块的受控运营接口里。每次操作记录操作者、原因和时间。只读看板不直接开放给普通用户。
哪些扩展点现在留
媒体服务、登录验证、通知、支付和 IM 这些外部服务留适配接口。需求、订单等模块之间只在真正需要调用的地方定义接口，不给每个类都套一层抽象。
可靠通知任务可以使用 PG 中的任务记录和应用内重试，按需加入；一期不要求部署 MQ。搜索先用 PG 的筛选与索引，达到实际瓶颈再换。
金额规则、取消规则和权益配置由业务模块持有，不能散落在前端。变化会影响已确认订单时，要保存历史版本。
编码约定
提交前执行格式、静态检查和必要测试。命名用业务含义，公开接口写清输入、结果与错误；状态变更集中到业务方法，避免任意 setter。数据库迁移可从空库建立开发环境。
日志不打印验证码、服务商密钥、完整证件和私聊正文。接口返回业务错误码与 requestId，便于从一次请求定位问题。