Какие ограничения есть у Feature-Sliced Design при построении сложных процессов?

Feature-Sliced Design (FSD) — это архитектурная методология для фронтенд-приложений, которая предлагает чёткое разделение кода по бизнес-фичам и техническим слоям. Однако при построении сложных процессов, таких как многоэтапная оплата, onboarding пользователя или workflow с обратной связью между модулями, могут проявиться её ограничения.

Ключевые ограничения FSD для сложных процессов

• Жёсткие границы слайсов: Сложные процессы часто требуют тесного взаимодействия нескольких фич (например, "корзина", "платёж", "уведомления"). В FSD прямое обращение из одного слайса в другой запрещено, что может привести к избыточным прокси-слоям или усложнению потока данных.
• Управление состоянием процесса: Состояние, относящееся к процессу (например, текущий шаг оформления заказа), может оказаться размазанным по нескольким слайсам. Размещение его в глобальном хранилище (Redux) частично нарушает принцип изоляции FSD.
• Маршрутизация и навигация: Сложные процессы часто имеют свою собственную многошаговую маршрутизацию (/checkout/step1, /checkout/step2), которая должна координироваться между слоями "features" и "pages". Это может создать нагромождение в слое pages.
• Потенциальное дублирование логики: Если разные фичи в процессе требуют похожих валидаций или преобразований данных, может возникнуть соблазн продублировать код, чтобы не нарушать границы слайсов.

Пример кода: Проблема с состоянием процесса

Рассмотрим процесс оформления заказа, который затрагивает фичи cart, shipping и payment. В идеальной FSD каждая фича управляет своим состоянием. Но состояние самого процесса (например, currentStep) не принадлежит ни одной из них явно.

// Проблематичное расположение состояния процесса внутри одной фичи
// features/checkout/model/store.ts
export const $checkoutProcess = createStore({
  currentStep: 'cart',
  isCompleted: false,
  // Данные из других фич приходится хранить здесь?
  shippingData: null,
  paymentData: null,
});

// Теперь фича shipping должна взаимодействовать с этим хранилищем,
// что создаёт зависимость от слайса checkout.

Практические подходы к смягчению ограничений

• Выделение "процессов" как отдельной сущности: Можно создать слой "processes" или использовать shared-хуки для координации, соблюдая правила FSD о направлении зависимостей (более высокие слои зависят от низших).
• Использование глобального шина событий или стейт-менеджера: Для связи между слайсами можно применять аккуратно спроектированные глобальные события, не создавая прямых импортов.
• Адаптация правил FSD: В крупных проектах иногда ослабляют строгость правил для cross-cutting concerns, вводя явные исключения для сложных бизнес-процессов.

Вывод: Feature-Sliced Design отлично подходит для структурирования приложений с чёткими, независимыми функциональными блоками. Однако для сложных, многошаговых процессов, требующих интенсивного взаимодействия между фичами, может потребоваться дополнительная архитектурная прослойка или компромисс в строгости методологии, чтобы избежать излишней сложности кода.