Architecture Patterns 🏗️

Large Next.js apps thrive on clear boundaries—organize code so teams can move independently.

Monolith vs Modular 🧱

• Monolith: single repo/app—simple but can get tangled.
• Modular Monorepo: Next.js app + packages (UI kit, utils) using PNPM workspaces, Turborepo, or Nx.
• Share ESLint configs, tsconfig bases, and design tokens.

Turborepo / Nx ⚙️

• Cache builds/tests per package.
• Define pipelines so only affected projects rebuild.
• Use apps/, packages/ structure.

Shared UI & Design Systems 🎨

• Extract components to packages/ui with Storybook documentation.
• Publish as internal npm packages or local workspace deps.

Domain-driven Design (DDD) 🧠

• Slice features by domain (billing, content, analytics) instead of tech layers.
• Each domain exposes APIs/hooks/components to the rest of the app.

Clean Architecture 🧼

• Keep business logic separate from frameworks; e.g., pure services imported into route handlers/server actions.
• Use dependency injection (simple factory functions) for testing.

API Layer Patterns 🧩

• BFF (Backend-for-Frontend): route handlers aggregate data from microservices for the UI.
• GraphQL: use Apollo/Urql; Next.js server components can fetch via graphql-request.
• tRPC: end-to-end typesafe API layer for React clients.

Feature Flags & Multi-tenant 🏁

• Use LaunchDarkly/GrowthBook or homemade flag service to toggle features per user.
• For multi-tenant apps, partition DB schemas or use tenant IDs; include tenant in cache keys and routing (subdomain tenant.example.com).

Analogy: architecture is city planning—zoning (domains), public transit (shared packages), and building codes (lint/config) keep the metropolis running smoothly.