frontend-patterns/research/candidates/VerticalFeatureSlice.md
tegwick b8eec87f08 Distinguish feature organization from independent release boundaries
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
2026-09-26 23:06:16 +02:00

50 lines
2.5 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
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.