Units

Module

Structural unit of the project

A module can be represented as 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.

Layer

Each project top level directory defines the scope of responsibility of modules, as well as the level of sensitivity to internal changes

• Representatives: app, processes, pages, widgets, features, entities, shared

└── src/
    ├── app/                    # Application initialization logic and static assets
    ├── processes/              # (Optional) Page-independent workflows or workflows involving multiple pages
    ├── pages/                  # Complete application views
    ├── widgets/                # Various combinations of abstract and / or business units from lower layers
    ├── features/               # (Optional) User scenarios, which usually operate on business entities
    ├── entities/               # (Optional) Business units in terms of which application business logic works
    └── shared/                 # Reusable non business specific modules

Slice

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

• Representatives (from each layer) process, page, widget, feature, entity

├── app/
|   # Application composition layer
|   # Only contains abstract initialization logic and static assets, and thus mustn't contain any Slices
|
├── processes/
|   # Slices implementing page-independent workflows or workflows involving multiple pages
|   ├── auth
|   ├── payment
|   ├── quick-tour
|   └── ...
|
├── pages/
|   # Slices implementing complete application views
|   ├── feed
|   |
|   ├── profile
|   |   # Due to routing specifics, this layer can contain nested structures
|   |   ├── edit
|   |   └── stats
|   |
|   ├── sign-up
|   └── ...
|
├── widgets/
|   # Slices implementing various combinations of abstract and / or business units from lower layers,
|   # to deliver isolated atomic User Interface fragments
|   ├── chat-window
|   ├── header
|   ├── feed
|   └── ...
|
├── features/
|   # Sliced implementing user scenarios, which usually operate on business entities
|   ├── auth-by-phone
|   ├── create-post
|   ├── write-message
|   └── ...
|
├── entities/
|   # Slices implementing business units in terms of which application business logic works
|   ├── account
|   ├── conversation
|   ├── post
|   ├── wallet
|   └── ...
|
├── shared/
|   # This layer is a set of abstract Segments
|   # It means that it must not contain any business units or business-related logic

Segment

Group of primitives serving as implementation details for business logic

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

• Representatives: ui, model, lib, api, config

{layer}/
    ├── {slice}/
    |   ├── ui/                     # User Interface components and UI related logic
    |   ├── model/                  # Business logic (store, actions, effects, reducers, etc.)
    |   ├── lib/                    # Infrastructure logic (utils/helpers)
    |   ├── config/                 # Local configuration (constants, enums, meta information)
    |   └── api/                    # Logic of API requests (api instances, requests, etc.)

note

Since some layers doesn't contain slices (app, shared):

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

See also

• Abstraction levels by methodology
• Layers in the methodology
• Segments in the methodology