docs(architecture): rewrite overview for vertical feature architecture

This commit is contained in:
2026-05-05 09:32:10 +02:00
parent d4969d2fb5
commit f6e86cf55e

View File

@@ -1,55 +1,58 @@
# Architecture Overview # Architecture Overview
## Clean Architecture Monorepo A vertical-feature monorepo. Business capabilities are top-level packages; non-business foundations are `core-*`.
This template implements Uncle Bob's Clean Architecture in a Turborepo + pnpm monorepo. The core principle: **dependencies point inward only**. ## Package map
``` ```
┌─────────────────────────────────────────────────┐ packages/
Frameworks & Drivers (outermost) │ # Foundation (no business logic)
Next.js, TanStack Start, Payload CMS, │ core-shared/ Generic primitives — Payload field/block helpers, tRPC init/context, lib utilities
Storybook, PostgreSQL, Docker │ core-cms/ Composition only: assembles feature CMS exports into one Payload config
│ ┌─────────────────────────────────────────┐ │ core-api/ Composition only: aggregates feature tRPC routers into one appRouter
│ Interface Adapters │ │ core-trpc/ Frontend tRPC client + per-framework providers (Next.js, TanStack)
tRPC routers, Controllers, Presenters │ │ core-ui/ Design-system primitives (atoms, molecules, generic organisms, templates)
│ │ ┌─────────────────────────────────┐ │ │
│ │ Application (Use Cases) │ │ │ # Business capabilities
Business logic, interfaces │ │ auth/ Users + sign-in/sign-up/sign-out + session/cookie domain
┌─────────────────────────┐ │ │ blog/ Articles collection + publishing flow
Entities (innermost) │ │ │ │ media/ Media upload collection (skeleton; expand with optimization, CDN, etc.)
│ │ │ Models, Errors, Zod │ │ │ │ marketing-pages/ Pages collection + SiteSettings global
└─────────────────────────┘ │ │ │ navigation/ Header global + menu items
│ │ └─────────────────────────────────┘ │ │
└─────────────────────────────────────────┘ │ # Tooling
└─────────────────────────────────────────────────┘ eslint-config/ Shared ESLint flat config + boundary rules
typescript-config/ Shared tsconfig + vitest base
``` ```
## Package Map ## Data flow
``` ```
packages/core → Clean architecture (entities, use cases, infra, DI) React component
packages/api → tRPC routers (calls core controllers) ↓ useQuery(trpc.blog.articleBySlug.queryOptions(...)) ← ui/query.ts (typed tRPC client)
packages/api-client → Shared React Query hooks + provider HTTP /api/trpc
packages/cms-core → Payload CMS config, collections, hooks
packages/cms-client → Dual-mode Payload client (local + HTTP) tRPC procedure ← integrations/api/router.ts
packages/ui → Atomic Design + shadcn/ui + Tailwind v4 ↓ .input(zod).query(...)
Controller (Zod safeParse) ← interface-adapters/controllers/
apps/web-next → Next.js 15 reference app
apps/web-tanstack → TanStack Start reference app Use case ← application/use-cases/
apps/cms → Thin Next.js shell for Payload admin ↓ container.get(SYMBOL)
apps/storybook → Centralized Storybook instance Repository implementation ← infrastructure/repositories/ (@injectable)
↓ getPayload({ config })
Payload Local API → Postgres
``` ```
## Data Flow ## Three enforcement layers
``` 1. **`package.json` deps** — only declare allowed deps
UI → useQuery(trpc.content.list) → tRPC Router → Controller → Use Case → Repository → Payload Local API → PostgreSQL 2. **`exports` map** — each package exposes a small public surface (`.`, `./cms`, `./api`, `./di/bind-production`)
``` 3. **ESLint `eslint-plugin-boundaries`** — three tags (`app`, `feature`, `core`); two composition exceptions (`core-api` may import `@repo/<feature>/api`; `core-cms` may import `@repo/<feature>/cms`)
## Key Design Decisions ## Per-feature DI containers
- **InversifyJS DI** — symbol-based resolution, documented in di/AGENTS.md Each feature owns its own InversifyJS `Container` + symbol table. No shared symbols, no cross-feature DI coupling. Tests rebind per feature without touching others. Apps call `bindProduction*(config)` per feature at boot to swap the default mock implementations for Payload-backed ones.
- **Dual-mode CMS client** — Local API for server-side (no HTTP overhead), HTTP for external
- **Atomic Design** — atoms/molecules/organisms/templates, co-located stories ## Spec reference
- **tRPC single data path** — all data (including CMS content) flows through tRPC
- **Agent-optimized docs** — AGENTS.md at every level with rules, recipes, tables `docs/architecture/vertical-feature-spec.md` is the canonical design.