Developer reference
Service and action boundary
Trace validated user intent from API routing to owned domain effects and fresh reads.
Routes authenticate the caller, validate scopes and request shape, then call user-scoped server services. Services express domain commands and use controlled financial RPCs.
Responsibilities by layer
| Layer | Responsibility |
|---|---|
| Browser helper | Send user intent and present pending/result/recovery state. |
| API router | Authenticate, authorize method/scope and validate transport input. |
| Service | Check ownership and financial domain rules. |
| Controlled database operation | Persist the atomic invariant. |
| Read model | Return a coherent answer with context. |
Browser helpers do not reconstruct financial SQL or hold privileged credentials.
Setup versus money
Creating a named income source and recording a receipt can both use POST, but they have different effects. Review the service’s actual operation rather than classifying effects by HTTP verb.
Adding a command
Verify owned accounts and semantic links, accepted fields, atomicity, idempotency where needed, safe error text and relevant read invalidation. An uncertain response must retain a way to recover the same action.
Evidence for the change
Use meaningful service and API tests, then the appropriate authorized runtime acceptance. A mocked successful response does not prove a provider or database interaction works.
See architecture flow, financial functions and testing boundaries.