Skip to main content

Decomposition of app

Group: Layersโ€‹

The first level of separation: according to the scope of responsibility of the module


"Which application layer does the module belong to?"

โ””โ”€โ”€ src/
โ”œโ”€โ”€ app/ # Initializing application logic
โ”œโ”€โ”€ processes/ # (Optional) Application processes running over pages
โ”œโ”€โ”€ pages/ # Application pages
โ”œโ”€โ”€ widgets/ # Independent and self-contained blocks for pages
โ”œโ”€โ”€ features/ # (Optional) Processing of user scenarios
โ”œโ”€โ”€ entities/ # (Optional) Business entities that domain logic operates with
โ””โ”€โ”€ shared/ # Reused modules, non business specific

Layers orderโ€‹

If you look at the order of the layers , you can distinguish two general patterns:

By the level of knowledge/responsibilityโ€‹

app > processes > pages > features > entities > shared

The module "knows" only about itself and the underlying modules, but not the ones lying above

This also affects the allowed imports

By the level of danger of changesโ€‹

shared > entities > features > pages > processes > app

The lower the module is located , the more dangerous it is to make changes to it

Because most likely it is used in many overlying layers

Group: Slicesโ€‹

The second level of separation is by specific BL functionality

The methodology has almost no effect on this level and much depends on the specific project


"What scope of BL does the module affect?"

Before that , it is necessary to determine the scope of responsibility (layer)

โ”œโ”€โ”€ app/
| # Does not have specific slices,
| # Because it contains meta-logic on the project and its initialization
โ”œโ”€โ”€ processes/
| # Slices implementing processes on pages
| โ”œโ”€โ”€ payment
| โ”œโ”€โ”€ auth
| โ”œโ”€โ”€ quick-tour
| โ””โ”€โ”€ ...
โ”œโ”€โ”€ pages/
| # Slices implementing application pages
| # At the same time, due to the specifics of routing, they can be invested in each other
| โ”œโ”€โ”€ profile
| โ”œโ”€โ”€ sign-up
| โ”œโ”€โ”€ feed
| โ””โ”€โ”€ ...
โ”œโ”€โ”€ widgets/
| # Slices implementing independent page blocks
| โ”œโ”€โ”€ header
| โ”œโ”€โ”€ feed
| โ””โ”€โ”€ ...
โ”œโ”€โ”€ features/
| # Slices implementing user scenarios on pages
| โ”œโ”€โ”€ auth-by-phone
| โ”œโ”€โ”€ inline-post
| โ””โ”€โ”€ ...
โ”œโ”€โ”€ entities/
| # Slices of business entities for implementing a more complex BL
| โ”œโ”€โ”€ viewer
| โ”œโ”€โ”€ posts
| โ”œโ”€โ”€ i18n
| โ””โ”€โ”€ ...
โ”œโ”€โ”€ shared/
| # Does not have specific slices
| # is rather a set of commonly used segments, without binding to the BL


Since a slice is a specific level of abstraction, the methodology is obliged to impose certain rules on it

Low Coupling & High Cohesionโ€‹

Slices of the same layer cannot use each other directly, and their interaction and composition should be determined on the upper layer, relative to their current one

// Bad: the feature imports another feature (slices of the same layer)
import { Bar } from "features/bar"

function Baz({ foo, ...barProps}) {
<Bar {...barProps} />
// Good: features are compiled on the page (overlying layer)
import { Baz } from "features/baz"
import { Bar } from "features/bar"

function Foo() {
<Baz {...fooProps}>
<Bar {...barProps} />


  • In most cases, you should avoid nesting in slices, and use only structural grouping by folders, without additional coupling logic

    features/order/           # Feature group
    โ”œโ”€โ”€ add-to-cart # Full-fledged feature
    โ”œโ”€โ”€ total-info # Full-fledged feature
    - โ”œโ”€โ”€ model.ts # General logic for the group
    - โ”œโ”€โ”€ hooks.ts # General hooks for the group
    โ””โ”€โ”€ index.ts # Public API with feature re-export
  • At the same time, some layers (e.g., pages) initially require nesting due to the requirements of the project / framework

    โ”œโ”€โ”€ order/
    | โ”œโ”€โ”€ cart/
    | โ”œโ”€โ”€ checkout/
    | | โ”œโ”€โ”€ delivery/
    | | โ””โ”€โ”€ payment/
    | โ”œโ”€โ”€ result/
    | โ””โ”€โ”€ index.tsx
    โ”œโ”€โ”€ auth/
    | โ”œโ”€โ”€ sign-in/
    | โ””โ”€โ”€ sign-up/
    โ”œโ”€โ”€ home/
    โ”œโ”€โ”€ catalog/

Nested slices should be avoided as much as possible, but even if you have to use them (for example, for pages), you need to link them explicitly, to avoid unforeseen consequences

Group: Segmentsโ€‹

The third level of separation: by the purpose of the module in the code and implementation


"What part of the technical implementation of the logic affects the module?"

Before that, it is necessary to determine the scope of influence (layer) and domain affiliation (slice)

โ”œโ”€โ”€ {slice}/
| โ”œโ”€โ”€ ui/ # UI-logic (components, ui-widgets,...)
| โ”œโ”€โ”€ model/ # Business logic (store, actions, effects, reducers,...)
| โ”œโ”€โ”€ lib/ # Infrastructure logic (utils/helpers)
| โ”œโ”€โ”€ config*/ # Configuration (of the project / slice)
| โ””โ”€โ”€ api*/ # Logic of API requests (api instances, requests,...)

At the same time, each segment can be represented as a file, or as a separate directory - depending on the complexity and size


The methodology was developed with the aim of not limiting and not bothering developers with the rules for choosing abstractions (it's desirable to use any segment in any layer)

However, as a result of discussions and analysis of extensive experience - it was determined that it is better and more practical to limit each layer to segments used internally.

General rulesโ€‹

  1. The higher the layer is located , the more it knows about the BL of the application and vice versa
  2. API logic recommended should be put in shared so that the logic is not scattered around the project
  • Usually, it is common and presented as single instances
    • Edge-case "exceptions": GraphQL, react-query hooks

Application for layersโ€‹

LayerContentAllowed Segments
appDoes not include slices and contains initialization logicThe existing segments are not quite suitable, and therefore /providers (/hoc, ...), /styles, etc. are usually used. It depends very much on the project and is unlikely to be solved by the methodology
processesThe slices inside include only business logic, without displaying (1)ui lib model (api)
pagesThe slices inside include a ui and model composition of various features for a specific pageui lib model (api)
featuresThe slices inside include the composition of entities and the implementation of BL in the model + displayui lib model (api)
entitiesThe slices inside represent a disparate set of submodules for usingui lib model (api)
sharedContains only infrastructure logic without BL (1)ui lib api

See alsoโ€‹