优化结构

internal/README.md

@@ -3,7 +3,8 @@
 系统模块承载当前管理后台的完整业务边界。`internal` 顶层只保留有明确
 生命周期或分层职责的包：
 
-- `app`：组合根、system 模块定义和任务/路由运行时组合
+- `app`：组合根、模块 catalog 和任务/路由运行时组合
+- `modules`：按业务模块维护 Definition 等模块贡献
 - `biz`：系统领域对象、用例和仓储接口
 - `conf`：基础配置 proto 与运行时配置解析
 - `data`：数据库生命周期、系统仓储、系统表和支付持久化
@@ -18,18 +19,19 @@
 
 目录代表边界，模块文件按资源命名。DTO、handler、中间件、路由和 HTTP
 响应工具分别放在独立子包中，避免 `service`/`server` 根目录堆积几十个
-文件，同时不把只有一两个文件的业务逻辑再拆成新包。单文件的 module
-定义并入 `app`，JWT 实现集中在 `security`，protobuf JSON 统一使用
+文件，同时不把只有一两个文件的业务逻辑再拆成新包。system 的 module
+定义位于 `modules/system`，JWT 实现集中在 `security`，protobuf JSON 统一使用
 `pkg/protoutil`。
 
-`internal/app` 只有 `catalog.go` 和 `definition.go` 是有意保留的组合根：
-前者组装模块 catalog、任务注册和运行时，后者声明 system 的迁移、管理面
-和定时任务。它们不是可以下沉到 `service` 或 `data` 的业务文件。
+`internal/app` 只保留 `catalog.go` 作为组合根：它负责组装模块 catalog、任务
+注册和运行时。system 的迁移、管理面和定时任务由 `internal/modules/system`
+自己的 `Definition()` 声明，便于后续业务模块独立接入。
 
 系统表统一使用 `sys_` 前缀；业务表应由新业务模块自行命名和迁移，不要混入
 本目录。
 
-system 通过 `Definition()` 提供迁移、支付菜单/API 和默认任务，通过
+system 通过 `modules/system.Definition()` 提供系统迁移、通信集成菜单/API 和默认任务；
+payment 通过 `modules/payment.Definition()` 提供支付迁移及支付菜单/API。两者通过
 `worker.TaskMethods` 提供依赖系统用例的任务实现，通过 `server/router.Routes` 提供
-路由。应用组合根消费这些公共协议；新增业务不需要修改 system 的初始化、
-worker、路由或数据层。
+路由。静态模块贡献可由 catalog 汇总；带运行时依赖的路由和任务仍需在 cmd/Wire
+中显式装配，不应误认为只添加 Definition 就能自动发现。