Should You Keep, Adopt, or Migrate Away from Feature Sliced Design?
For Teams currently using or evaluating Feature Sliced Design · Based on Dima's 5-Rule Front-End Architecture Evaluator
// TL;DR
Feature Sliced Design has real strengths — good slice-level cohesion, enforced public APIs, and a shared vocabulary. But it also has trade-offs that the 5-Rule Evaluator surfaces: low feature-level cohesion, the Classification Problem, poor Incremental Adoption, and shared-layer bloat risk. Use this framework to score your FSD implementation objectively, decide whether to keep it with targeted fixes or migrate to Vertical Slices, and avoid the common mistake of conflating FSD's slice-level cohesion with true feature-level cohesion.
Is Feature Sliced Design actually improving your codebase?
FSD provides structure, but structure alone doesn't guarantee quality. Run the 5-Rule audit on your current FSD implementation to find out.
Score High Cohesion by tracing one complete business feature — say, the add-to-cart flow. Count how many layers you touch: you might need code in `features/cart`, `entities/product`, `entities/cart`, `widgets/product-card`, and `shared/ui`. If you're opening files across four or five layers for one user-facing feature, your feature-level cohesion is low — even though each individual slice is well-organized internally.
This distinction between slice-level and feature-level cohesion is the most commonly missed insight about FSD.
Does your team have the Classification Problem?
Run the test: ask three developers independently where they'd place a search component that filters products, appears on multiple pages, and contains business logic for search suggestions. Possible answers in FSD include `features/search`, `widgets/search-bar`, `entities/search`, or even `shared/ui/search`.
If your team disagrees — and most FSD teams do on components like this — you have the Classification Problem. This means your Discoverability score is lower than FSD's structure promises. Developers waste time debating placement instead of building features, and similar components end up in different layers depending on who wrote them.
When should you keep FSD and when should you migrate?
Keep FSD if all three conditions are true: your project is large and long-lived (100+ components, 12+ months ahead), your team is genuinely fluent in FSD vocabulary and placement rules, and you accept the classification overhead as a manageable cost.
If you keep FSD, enforce two practices: use the `@x` notation for all cross-slice dependencies to make coupling visible, and audit the `shared` layer monthly for business logic creep. Components with domain-specific names like `AddToCartButton` in shared are a red flag.
Migrate away from FSD if your project is small or medium, your team frequently disagrees about placement, or onboarding new developers takes longer than it should. Migrate to Vertical Slices incrementally: collapse each business domain's code from multiple FSD layers into one feature folder with UI, logic, and API sub-folders.
How do you migrate from FSD to Vertical Slices incrementally?
Pick the most painful domain first — the one causing the most merge conflicts or confusion. Create a top-level folder named after that domain (e.g., `cart`). Move all related code from `features/cart`, `entities/cart`, `entities/product` (cart-related parts), and `widgets/cart-summary` into sub-folders inside the new `cart` folder.
Update imports gradually. Keep the rest of your code in FSD's layer structure until you migrate each domain. This approach minimizes risk and lets you validate the Vertical Slices pattern on one domain before committing fully.
After migrating two or three domains, re-run the 5-Rule audit. You should see improved scores on feature-level cohesion, Mental Model Match (top-level folders now scream what the app does), and Discoverability (fewer ambiguous placement decisions).
Ready to audit your FSD implementation? Gather your project description, team size, known pain points, and run through the 10-step workflow to get an objective verdict.
// FREQUENTLY ASKED QUESTIONS
Does Feature Sliced Design have good cohesion?
FSD has good slice-level cohesion — code within each slice is well-organized with clear segments (UI, model, API). But it has low feature-level cohesion because one business feature's code is scattered across multiple layers (features, entities, widgets). The 5-Rule Evaluator makes this distinction explicit, which is the most commonly missed insight about FSD.
What's wrong with FSD's shared layer?
The shared layer tends to become a dumping ground for any code that doesn't fit cleanly into a specific layer. Over time, business-specific components sneak in — violating shared's rule of containing no business logic. Audit it regularly: anything with domain-specific naming (like AddToCartButton) should be relocated to the appropriate feature slice or domain folder.
Can I use Vertical Slices and FSD concepts together?
Yes. You can adopt FSD's best concepts — public APIs via index files, segments for internal organization, and explicit cross-module contracts — within a Vertical Slices structure. Organize primarily by business domain (cart, checkout, user) and use FSD-style segments (UI, model, API) as sub-folders within each domain. This gives you feature-level cohesion with FSD's internal organization quality.