37 lines
1.0 KiB
Markdown
37 lines
1.0 KiB
Markdown
|
# Service Standards
|
||
|
|
|
||
|
|
Status: Mandatory
|
||
|
|
Date: 2026-07-03
|
||
|
|
|
||
|
|
## Service Categories
|
||
|
|
|
||
|
|
- Domain Service: business operations and rules.
|
||
|
|
- Integration Service: external API/system communication.
|
||
|
|
- Platform Service: cross-cutting platform concerns.
|
||
|
|
|
||
|
|
## Rules
|
||
|
|
|
||
|
|
- Services must have one clear responsibility.
|
||
|
|
- Services should expose typed contracts only.
|
||
|
|
- Services should avoid UI-specific formatting.
|
||
|
|
- Services should not depend on component classes.
|
||
|
|
- Shared services must not depend on feature modules.
|
||
|
|
|
||
|
|
## Facade Interaction
|
||
|
|
|
||
|
|
- Components call facades.
|
||
|
|
- Facades call services.
|
||
|
|
- Services do not call UI components.
|
||
|
|
|
||
|
|
## Stable Module Protection
|
||
|
|
|
||
|
|
- Existing authentication, payment, authorization services remain behavior-compatible.
|
||
|
|
- Wrap legacy stable behavior with adapters where needed.
|
||
|
|
- No contract changes for auth/payment APIs.
|
||
|
|
|
||
|
|
## Storage and Runtime Access
|
||
|
|
|
||
|
|
- Browser storage access allowed only in approved service boundaries.
|
||
|
|
- Prefer abstraction interfaces for storage access.
|
||
|
|
- Never use storage APIs in UI components.
|