1.3 KiB
1.3 KiB
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