- name
- api-conventions
- description
- Service structure conventions for this codebase: routing, layering, and where code lives. Use whenever writing or modifying a service's server entry, route definitions, handlers, or adapters. Loads inline so it shapes structure as code is written.
# Service Architecture Conventions
Every service is three layers, one direction: `server.ts` → `handlers/` → `adapters/`. Apply while writing, not after.
## Versioning
- All routes live under `/api/v1/`. New endpoints are versioned from the first line. No unversioned routes "for now."
## server.ts is thin
- `server.ts` defines routes and delegates. Nothing else.
- No business logic in `server.ts` or in a route definition. A route wires the request to a handler and returns its result.
## handlers/ hold the logic
- Business logic lives in `handlers/`, one file per domain.
- A handler owns its domain's rules and orchestration. It calls adapters for anything external. It does not reach outside the process itself.
## adapters/ wrap everything external
- Database, external APIs, queues, anything outside the process goes through an adapter in `adapters/`. Handlers never touch them directly.
- **The database adapter uses StrictDB when it's installed, otherwise the native driver. Never Mongoose.** A handler that imports a driver or calls an external API inline is wrong, that belongs in an adapter. The data adapter is the one place driver code lives, which is also where the `mongodb-rules` apply.
## Service (package) separation
- A service owns its domain and is reached through its interface. A package does not reach into another package's internals or its data. Call the owning service.
- Code two services both need is hoisted to a shared layer, never imported sideways from a sibling.
The test: routes in `server.ts` read request-in, handler-call, response-out. Logic sits in `handlers/`. Anything that leaves the process goes through `adapters/`, and the data adapter uses StrictDB if installed, the native driver otherwise.
GitHub에서 보기