# ADR-006: Vertical Feature Packages

**Status:** Accepted
**Date:** 2026-05-04

## Context

The original template organized packages by architectural layer: `core` (all domains together), `api` (all routers), `ui` (all components). As features grow, shared code accumulates and cross-feature dependencies become implicit.

## Decision

Reorganize by business capability. Each feature owns a vertical slice from entities through UI. `core-*` packages host only non-business concerns (DI, shared types, UI primitives).

**Result:** 5 feature packages (`auth`, `blog`, `media`, `marketing-pages`, `navigation`) + 5 core packages (`core-shared`, `core-cms`, `core-api`, `core-trpc`, `core-ui`).

## Consequences

- Features evolve independently without coordinating with shared code
- Cross-feature coupling is visible at the package-graph level (ESLint enforces it)
- Per-feature DI containers eliminate symbol collisions
- New team members can understand a feature completely by reading one package

## Alternatives Considered

- Horizontal layers (kept): Simpler initially, but scales to implicit hidden dependencies
- Monolithic single package: No modularity, impossible to reason about at scale
- Feature shells + shared core: Hybrid approach tried by many teams; creates "dump" in core that nobody owns