45 lines
2.8 KiB
Markdown
45 lines
2.8 KiB
Markdown
# System Module
|
||
|
||
系统模块承载当前管理后台的完整业务边界。`internal` 顶层只保留有明确
|
||
生命周期或分层职责的包：
|
||
|
||
- `app`：运行时组合根，负责依赖注入后的任务/路由组合
|
||
- `modules`：静态模块 catalog，按 system/integration/task/payment 维护 Definition
|
||
- `biz/system`：用户、权限、菜单、审计、媒体和系统配置领域
|
||
- `biz/payment`：支付订单、支付流程、支付接口和支付日志
|
||
- `biz/integration`：集成配置定义、校验和连接测试边界
|
||
- `biz/task`：定时任务模型、用例和任务注册协议
|
||
- `conf`：基础配置 proto 与运行时配置解析
|
||
- `data`：共享数据库生命周期；仓储按 `data/system`、`data/integration`、`data/task`、`data/payment` 隔离
|
||
- `initialize`：数据库首次初始化和系统种子数据编排
|
||
- `integration`：Redis、邮件、对象存储、支付、WebSocket、EMQX 和 RabbitMQ 适配器
|
||
- `routecatalog`：统一声明 HTTP 路由的公开性、操作审计、请求体策略和 API 元数据
|
||
- `security`：后台 JWT 等安全实现
|
||
- `server`：Gin server 组合与生命周期；横切 HTTP 代码按子包维护：
|
||
`server/handler`、`server/middleware`、`server/router`、`server/httpx`
|
||
- `service`：应用服务、DTO 与领域对象转换；DTO 集中在
|
||
`service/dto`，根包中的 `dto_aliases.go` 只负责兼容旧调用方
|
||
- `worker`：定时任务执行与调度
|
||
|
||
目录代表边界，模块文件按资源命名。DTO、handler、中间件、路由和 HTTP
|
||
响应工具分别放在独立子包中，避免 `service`/`server` 根目录堆积几十个
|
||
文件，同时不把只有一两个文件的业务逻辑再拆成新包。system 的 module
|
||
定义位于 `modules/system`，JWT 实现集中在 `security`，protobuf JSON 统一使用
|
||
`pkg/protoutil`。
|
||
|
||
`internal/modules/catalog.go` 是静态模块 catalog 的唯一注册点，负责按依赖顺序
|
||
汇总各模块 Definition。`internal/app/runtime.go` 只负责依赖注入后的任务注册
|
||
和路由运行时组合。这样新增模块只需在 modules catalog 注册一次，app 不再重复
|
||
维护模块声明。
|
||
|
||
系统表统一使用 `sys_` 前缀；业务表应由新业务模块自行命名和迁移，不要混入
|
||
本目录。
|
||
|
||
system 通过 `modules/system.Definition()` 提供系统迁移；integration 通过
|
||
`modules/integration.Definition()` 提供通信集成菜单/API；task 通过
|
||
`modules/task.Definition()` 提供定时任务迁移和默认任务；
|
||
payment 通过 `modules/payment.Definition()` 提供支付迁移及支付菜单/API。两者通过
|
||
`worker.TaskMethods` 提供依赖系统用例的任务实现，通过 `server/router.Routes` 提供
|
||
路由。静态模块贡献可由 catalog 汇总；带运行时依赖的路由和任务仍需在 cmd/Wire
|
||
中显式装配，不应误认为只添加 Definition 就能自动发现。
|