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

2.5 KiB
Raw Permalink Blame History

title status maturity families scales admission
Vertical Feature Slice draft hypothesis
composition
L4
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; feature boundaries need not coincide with Failure Boundary.

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. 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 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: release cadence adds activation/version contracts that source grouping alone does not provide.