23bc29ce0f
|
||
|---|---|---|
| .. | ||
| migration | ||
| payment | ||
| system | ||
| README.md | ||
| admin_config_compat.go | ||
| config_management.go | ||
| config_store.go | ||
| config_watch.go | ||
| data.go | ||
| data_scope.go | ||
| data_scope_audit.go | ||
| data_scope_audit_test.go | ||
| data_scope_record.go | ||
| data_scope_test.go | ||
| database.go | ||
| gorm_logger_test.go | ||
| initialization.go | ||
| integration_config.go | ||
| integration_config_test.go | ||
| migrations.go | ||
| mongo.go | ||
| runtime_clients.go | ||
| system_init.go | ||
| system_init_state_test.go | ||
README.md
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/systemcontains 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/paymentcontains payment configuration and payment-order persistence. Provider SDK implementations are separate ininternal/integration/payment.internal/data/migrationcontains 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.