Skip to main content



Structural unit of the project

A module usually means a specific file or directory (an abstraction in the context of a structure)

  • authorization module
  • page module
  • the module of the component in the feature
  • action module in the entity model
  • etc.


Each of the directories located at the topmost level of the application.

This level defines the scope of responsibility of modules, as well as the level of danger of changes

└── src/    β”œβ”€β”€ app/                    # Initializing application logic    β”œβ”€β”€ processes/              # (Optional) Application processes running over pages    β”œβ”€β”€ pages/                  # Application Pages    β”œβ”€β”€ features/               # Crucial functionality of the application    β”œβ”€β”€ entities/               # Business entities    └── shared/                 # Reused modules


Each of the elements located at the top level of the layers

This level is poorly regulated is a methodology, but a lot depends on the specific project, stack and team

β”œβ”€β”€ app/|   # Does not have specific slices, |   # Because it contains meta-logic on the project and its initializationβ”œβ”€β”€ processes/|   # Slices for implementing processes on pages|   β”œβ”€β”€ payment|   β”œβ”€β”€ auth|   β”œβ”€β”€ quick-tour|   └── ...β”œβ”€β”€ pages/|   # Slices for implementing application pages|   # At the same time, due to the specifics of routing, they can be invested in each other|   β”œβ”€β”€ profile|   β”œβ”€β”€ sign-up|   β”œβ”€β”€ feed|   └── ...β”œβ”€β”€ features/|   # Slices for implementing specific functionality 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


Each of the modules located at the top level of each slice

This level determines the purpose of modules in the code and implementation, according to classical design models

{layer}/    β”œβ”€β”€ {slice}/    |   β”œβ”€β”€ ui/                     # UI-logic (components, ui-widgets, ...)    |   β”œβ”€β”€ model/                  # Business logic (store, actions, effects, reducers, ...)    |   β”œβ”€β”€ lib/                    # Infrastructure logic (utils/helpers)    |   β”œβ”€β”€ config/                 # Application configuration (env-vars, ...)    |   └── api/                    # Logic of API requests (api instances, requests, ...)

Since not every layer explicitly uses slices (app, shared)

  • Segments can be arranged according to their own rules shared/{api, config}
  • Or not to use app/{providers, styles} at all

See also#