28 lines
1.3 KiB
Markdown
28 lines
1.3 KiB
Markdown
# 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
|