---
title: Vertical Feature Slice
status: draft
maturity: hypothesis
families: [composition]
scales: [L4]
admission: research-candidate-only
---

# Vertical Feature Slice

Context: one product change spans UI, state and service interaction scattered across
technical folders. Change locality competes with reuse and cross-feature coordination.

Proposed solution: group the frontend parts of a cohesive capability behind an
explicit public interface. Declare permitted dependencies and compose capabilities
at a higher boundary. Put shared primitives where their ownership is clear; do not
hide cross-feature workflows inside another feature's private modules.

Result: a capability can evolve internally, but interface design and shared concepts
need maintenance. A folder or barrel export does not enforce isolation. This is a
source-code boundary, not proof of independent deployment, team autonomy, security
isolation or an end-to-end backend service boundary.

Evidence: B03 locates Feature-Sliced Design's product-oriented grouping and public
API rules. The proposed pattern abstracts those mechanisms without adopting its
entire layer taxonomy. Full-pattern application recurrence remains unverified.
Alternative: technical layers for a small cohesive application; extract shared
behavior only when its ownership and consumers justify the new coupling.

Proposed relation: may contain [Presentation Model](PresentationModel.md); feature
boundaries need not coincide with [Failure Boundary](FailureBoundary.md).

Next test: change one capability's storage adapter; inspect imports and consumer
contracts. Change only deployment cadence next and identify new obligations.

Evidence locators: [breadth review](../reviews/PatternBreadthExpansion.md).
All relations are research proposals; no canonical identity or admitted graph edges.
The next test is planned, not executed. Known uses of the complete proposed contract
have not been verified in this investigation.

## Pinned source-layout contrast — 2026-09-26

[Boundary review](../reviews/FeatureDeploymentBoundaries.md) D01–D03 locates public
feature entry points, UI/model separation and page composition in a pinned FSD todo
example, alongside one application build script. The shared entity/API layer means
feature grouping does not imply a private persistence adapter. This is a partial
static use, not a release or import-enforcement test. Compare
[Independent Feature Boundary](IndependentFeatureBoundary.md): release cadence adds
activation/version contracts that source grouping alone does not provide.