kra-new/internal/README.md

System Module

系统模块承载当前管理后台的完整业务边界。internal 顶层只保留有明确 生命周期或分层职责的包：

• app：组合根、模块 catalog 和任务/路由运行时组合
• modules：按业务模块维护 Definition 等模块贡献
• biz/system：用户、权限、菜单、审计、媒体和系统配置领域
• biz/payment：支付订单、支付流程、支付接口和支付日志
• biz/integration：集成配置定义、校验和连接测试边界
• biz/task：定时任务模型、用例和任务注册协议
• conf：基础配置 proto 与运行时配置解析
• data：数据库生命周期、系统仓储、系统表和支付持久化
• 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/app 只保留 catalog.go 作为组合根：它负责组装模块 catalog、任务 注册和运行时。system 的迁移、管理面和定时任务由 internal/modules/system 自己的 Definition() 声明，便于后续业务模块独立接入。

系统表统一使用 sys_ 前缀；业务表应由新业务模块自行命名和迁移，不要混入 本目录。

system 通过 modules/system.Definition() 提供系统迁移、通信集成菜单/API 和默认任务； payment 通过 modules/payment.Definition() 提供支付迁移及支付菜单/API。两者通过 worker.TaskMethods 提供依赖系统用例的任务实现，通过 server/router.Routes 提供 路由。静态模块贡献可由 catalog 汇总；带运行时依赖的路由和任务仍需在 cmd/Wire 中显式装配，不应误认为只添加 Definition 就能自动发现。