优化结构

internal/service/README.md

@@ -2,8 +2,28 @@
 
 `service` adapts HTTP-facing DTOs to business usecases and owns application
 orchestration. Request/response/filter contracts live in `dto/`; the root
-package contains resource services, conversions, and security
-coordination.
+package is a compatibility facade and module provider aggregator.
 
-`dto_alias.go` is a compatibility bridge for existing service callers. New
-transport code should import `service/dto` directly when it needs a contract.
+Implementations are grouped by the same business modules as `biz` and `data`:
+
+| Directory | Responsibility |
+| --- | --- |
+| `system/` | authentication, users, authorization, menus, organization, dictionaries, settings, audit, media, announcements, email, versions, exports |
+| `payment/` | payment orchestration and callback handling |
+| `integration/` | integration configuration orchestration |
+| `task/` | scheduled task orchestration |
+| `dto/` | HTTP request/response contracts |
+
+The stateless router-prefix helper lives in `internal/utils/routepath` because
+both service modules and HTTP middleware use it; it does not depend on a
+business usecase or DTO.
+
+Each module owns its Wire `ProviderSet`. The root `service` package re-exports
+the existing service types and constructors through aliases and thin wrappers, so handlers, middleware
+and generated Wire code can migrate independently without a flag day.
+
+Within `system/`, larger cross-cutting resources stay in the same package while
+being split by concern (`audit.go` and its error/log companions, `media.go` and
+upload companion, and `export.go`/`export_excel.go`). New transport code should
+import the module package directly when it does not need the compatibility
+facade.