design-patterns-and-conventionslisted

Enforce consistent design patterns, naming conventions, and architectural decisions across FastAPI backends, derived from real-world production services. ## When to use - Architecting new FastAPI services or major features - Reviewing code structure and organization - Establishing conventions for a new backend module - Refactoring existing code for consistency - Investigating or preventing technical debt - Questions about layered architecture, dependency injection, or configuration management - Setting up singleton instances, factory patterns, or custom API routes - Organizing multi-mode entrypoints (server/consumer/worker in one image) - Evaluating or auditing code for anti-patterns ## Core conventions ### Layered architecture - **Router/View → Service → Helper → DAO/Repository → Model** is the canonical flow. Router handles HTTP concerns, service contains business logic, DAO/repository owns data access. - Service layer MAY be thin or absent for pure CRUD operations where the router delegates directly to a DAO. - Never mix business logic into routers or DAOs; keep separation strict. ### Dependency injection - Use FastAPI `Depends()` for injecting context (database sessions, configuration, event emitters). - Example pattern: `async def get_connection_handler_for_app() -> AsyncGenerator[ConnectionHandler, None]` yields a handler, then closes it in `finally`. - NO dependency injection container; favor function-scoped generators and `Depends`. ### Configuration singleton -