部署和开发顺序
一期部署
一台项目主机放反向代理、Spring Boot 应用、PostgreSQL 和 Redis。PG、Redis 只在内部网络监听，应用通过内部连接访问。客户端只访问 HTTPS 业务入口，图片和视频走阿里云。
应用配置来自部署环境，仓库只放示例。开发、测试与正式环境使用各自的库、存储目录和凭证。这里是部署设计，本资料库没有启动这些服务，也没有配置真实业务环境。
看板和日常检查
一期保留只读看板：注册与审核数、有效需求、投递与邀约、确认合作、完成、取消与争议、预计服务费及实收。每个指标说明时间范围和统计口径；演示数据不混进真实统计。
同时观察接口错误、响应耗时、数据库连接、慢查询、媒体失败与重试积压。日志带 requestId 和必要业务 ID，隐藏个人资料和密钥。运营操作使用受控接口，不让看板直接写业务表。
备份和恢复
PG 做独立于项目主机的备份，按可接受的数据损失和恢复时间定频率。发布前确认迁移与回滚办法；定期在隔离环境恢复一次，核对订单、确认记录和费用是否一致。
Redis 不能成为订单或收款的唯一数据来源。清空缓存后应能从 PG 重建，验证码与会话按规则失效。媒体资源保留业务引用及必要的供应商记录，删除时核对引用与保留规则。
什么时候拆
先看真实负载和维护需求。PG 需要更好的备份、容量或故障隔离时迁出主机；Redis 因会话或缓存负载再拆。消息、视频回调或通知成为瓶颈时，按模块增加独立任务处理，不先按未来规模拆一排服务。
开发顺序
- 搭项目、格式检查、配置与数据库迁移；确定接口错误和权限约定。
- 做账号、酒吧与艺人资料、审核和媒体上传。
- 做需求、投递、邀约与文字沟通。
- 做条件版本、双方确认、订单与档期占用。
- 做完成、取消、变更和争议记录，再接只读看板。
- 收费规则确认后实现会员支付和权益；服务费统计与实收继续分开。
每一步都交付能运行的一个流程，不用等所有页面和扩展功能齐了再联调。
验收时实际检查
- 不能操作别人的需求、邀约、消息、私有文件和订单。
- 修改条件后，旧确认请求不能生成订单。
- 同一动作重复提交，仍只有一条投递、一份订单或一次权益开通。
- 同一艺人并发确认冲突时段，只允许一个成功，失败事务没有半份订单。
- 跨午夜时间能正确记录；金额不会把预算、估算或未收款当实收。
- 取消和改期保留原因与历史；新档期失败时旧订单继续有效。
- 媒体回调重复、乱序或丢失能恢复；私人资质不会公开。
- 备份能恢复；升级前后的迁移经过验证。
这些是业务后端实现的验收要求。当前只有文档、原型和设计图，后端还没有实现这些要求。