Skip to main content

Slices and segments


Slices are the second level in the organizational hierarchy of Feature-Sliced Design. Their main purpose is to group code by its meaning for the product, business or just the application.

The names of slices are not standardized because they are directly determined by the business domain of your application. For example, a photo gallery might have slices photo, create-album, gallery-page. A social network would require different slices, for example, post, add-user-to-friends, news-feed.

Closely related slices can be structurally grouped in a directory, but they should exercise the same isolation rules as other slices โ€” there should be no code sharing in that directory.

Features "compose", "like" and "delete" grouped in a directory "post". In that directory there is also a file "some-shared-code.ts" that is crossed out to imply that it's not allowed.

The layers Shared and App don't contain slices. That is because Shared should contain no business logic at all, hence has no meaning for the product, and App should contain only code that concerns the entire application, so no splitting is necessary.

Public API rule on slicesโ€‹

Inside a slice, the code could be organized very liberally, and that doesn't pose any issues as long as the slice provides a good public API. This is enforced with the public API rule on slices:

Every slice (and segment on layers that don't have slices) must contain a public API definition.

Modules outside of this slice/segment can only reference the public API, not the internal file structure of the slice/segment.

Read more about the rationale of public APIs and the best practices on creating one in the Public API reference.


Segments are the third and final level in the organizational hierarchy, and their purpose is to group code by its technical nature.

There a few standardized segment names:

  • ui โ€” UI components, data formatting functions
  • model โ€” business logic and data storage, as well as functions to manipulate this data
  • lib โ€” auxiliary and infrastructural code
  • api โ€” communication with external APIs, backend API methods

Custom segments are permitted, but should be created sparingly. The most common places for custom segments are the App layer and the Shared layer, where slices don't make sense.


SharedUI kitUsually not usedUtility modules of several related files.
If you need to use individual helpers, consider using utility libraries such as lodash-es.
Rudimentary API client with additional features like authentication or caching.
EntitiesSkeleton of a business entity with slots for interactive elementsData storage of instances of this entity as well as functions for manipulating that data.
This segment is most fit for storing server-side data. If you use TanStack Query or other methods of implicit storage, you may choose to omit this segment.
Functions for manipulating instances of this entity that aren't related to storageAPI methods using the API client from Shared for easy communication with the backend
FeaturesInteractive elements that enable users to use this featureBusiness logic and infrastructure data storage, if needed (e.g., current app theme). This is the code that actually produces value for the user.Infrastructural code that helps to concisely describe the business logic in the model segmentAPI methods that represent this feature on the backend.
May compose API methods from Entities.
WidgetsComposition of Entities and Features into self-contained UI blocks.
Can also contain error boundaries and loading states.
Infrastructure data storage, if neededNon-business interactions (e.g., gestures) and other necessary code for the block to function on a pageUsually not used, but can contain data loaders in nested routing contexts (e.g., Remix)
PagesComposition of Entities, Features and Widgets into complete pages.
Can also contain error boundaries and loading states.
Usually not usedNon-business interactions (e.g., gestures) and other necessary code for the page to deliver a complete user experienceData loaders for SSR-oriented frameworks