backend-architecture-corelisted

# Backend Architecture Core Shared model for the `backend-architecture` cluster. The architecture, API, integration, and deploy spokes all depend on these interlocking concepts — keep them consistent here so no spoke contradicts another. ## 1. The decision this cluster turns on: dependencies point inward Every spoke is an application of one rule — **the domain depends on abstractions, never on infrastructure**. Business logic is pure; frameworks, drivers, and HTTP clients live at the edges behind ports. This is the ports-and-adapters (hexagonal) boundary, and it is what makes a backend testable, framework-swappable, and resistant to rot. ``` (driving / inbound) (driven / outbound) HTTP · CLI · queue · cron ──> [Port] ──> Domain + Use cases ──> [Port] ──> DB · API · bus · cache adapters (no framework imports) adapters ``` - **Domain / use case** — pure business rules and orchestration; imports nothing from the framework, ORM, or transport. → `hexagonal-architecture` - **Port** — an interface the core owns and depends on (e.g. `UserRepository`, `PaymentGateway`). - **Adapter** — a concrete implementation at the edge (Express handler, NestJS controller, Prisma repo, an outbound API connector). Adapters depend on the core; the core never depends on them. **Rule:** if removing a library would force you to rewrite a use case, the dependency is pointing the wrong way — put a port between them. ## 2.