2026-09-26 21:46:28 +02:00
|
|
|
|
---
|
|
|
|
|
|
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.
|
2026-09-26 23:06:16 +02:00
|
|
|
|
|
|
|
|
|
|
## 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.
|
