30 lines
1.4 KiB
Markdown
30 lines
1.4 KiB
Markdown
# Service Layer
|
|
|
|
`service` adapts HTTP-facing DTOs to business usecases and owns application
|
|
orchestration. Request/response/filter contracts live in `dto/`; the root
|
|
package is a compatibility facade and module provider aggregator.
|
|
|
|
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.
|