36 lines
1.7 KiB
Markdown
36 lines
1.7 KiB
Markdown
# 系统架构总览
|
||
|
||
## 1. 文档目标
|
||
说明射箭赛事平台四个代码工程之间的职责分工、调用关系与边界，作为后续系统设计和开发拆分依据。
|
||
|
||
## 2. 四个工程的定位
|
||
| 工程 | 面向对象 | 核心职责 |
|
||
| --- | --- | --- |
|
||
| 微信小程序 | 参赛用户 | 浏览赛事、报名支付、查看通知与成绩 |
|
||
| 商户后台 | 赛事主办方 | 维护赛事、处理报名、录入成绩、查看数据 |
|
||
| 管理后台 | 平台运营 | 审核商户、审核赛事、风控治理、报表统计 |
|
||
| 后台 API 服务 | 全部客户端 | 提供统一业务接口、权限控制、订单支付、成绩与消息能力 |
|
||
|
||
## 3. 推荐逻辑架构
|
||
- 展示层：微信小程序、商户后台、管理后台
|
||
- 接口层：统一后台 API
|
||
- 领域层：用户、商户、赛事、报名、订单、成绩、通知、审核
|
||
- 基础设施层：数据库、缓存、对象存储、消息通知、支付能力
|
||
|
||
## 4. 系统交互关系
|
||
1. 用户通过微信小程序调用后台 API 完成登录、报名、支付。
|
||
2. 商户后台调用后台 API 完成赛事管理、报名管理、成绩录入。
|
||
3. 管理后台调用后台 API 完成审核、运营配置、数据查询。
|
||
4. 后台 API 对接微信登录、微信支付、短信/订阅消息等第三方能力。
|
||
|
||
## 5. 设计原则
|
||
- 业务规则统一收敛在后台 API，避免多端逻辑分叉。
|
||
- 商户与平台的权限边界必须清晰隔离。
|
||
- 接口设计优先稳定、可扩展、可审计。
|
||
- 文档命名与术语优先统一，便于 agent 自动续写。
|
||
|
||
## 6. 当前待定项
|
||
- 前端框架与后端语言尚未确定。
|
||
- 是否采用单体架构还是模块化服务架构待后续决策。
|
||
- 消息通知、对象存储、日志平台的具体选型待确认。
|