29 lines
1.4 KiB
Markdown
29 lines
1.4 KiB
Markdown
# Data Layer
|
|
|
|
`internal/data` is the persistence composition root. It owns the shared
|
|
database/runtime container (`Data`), database clients, configuration storage,
|
|
and the Wire `ProviderSet`. Business repositories live in submodules so a new
|
|
feature can be found by its domain instead of by scanning one large package.
|
|
|
|
## Modules
|
|
|
|
- `internal/data/system` contains the built-in administration domain: users,
|
|
authorities, APIs, permissions, menus, organization, dictionaries,
|
|
parameters, tokens, security, audit/logging, media, announcements, tasks,
|
|
versions, exports, bootstrap seeding, and system migrations.
|
|
- `internal/data/payment` contains payment configuration and payment-order
|
|
persistence. Provider SDK implementations are separate in
|
|
`internal/integration/payment`.
|
|
- `internal/data/migration` contains the version-table runner used by the
|
|
root migration coordinator.
|
|
|
|
The root package intentionally keeps only cross-cutting infrastructure:
|
|
database lifecycle/reloads, runtime configuration persistence, data-scope
|
|
auditing, integration configuration storage, and migration orchestration.
|
|
Repositories depend on narrow module seams (`system.Provider` and
|
|
`payment.Provider`) rather than importing the root implementation details.
|
|
|
|
Non-database adapters remain under `internal/integration` (storage, email,
|
|
payment SDKs, and cache), while reusable GORM and pagination helpers live in
|
|
`pkg/gormkit` and `pkg/pagination`.
|