phase-1: scaffold platform foundation structure and architecture governance
This commit is contained in:
36
docs/architecture/foundation/Service-Standards.md
Normal file
36
docs/architecture/foundation/Service-Standards.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user