here is the summary of 2 videos this & this this is not only about folder structures, but also how modules interact with each other in that folders 4 different architecture design approaches are reviewed here Classical can be seen in simple apps and youtube tutorials it is not an architecture, but simply tech oriented folder structure applicable for small projects, prototypes, no team involved with this approach components like pages are isolated but rest of all are not components are interconnected ui components are mixed with business logic at the end we end up in decoupled chaos without clear data flow Modular Layers it is already an architecture with data flow rules it has mandatory layers modules inside have business oriented segments, which do not interact with each other module is responsible for one task & ideally has all needed to do the task data flows vertically, code from lower layers can not import data from upper layers other folders will naturally appear and permitted UI UI layer has most generic UI blocks without any logic Components components layer contains a bit more complex components that may use blocks from ui may include minimal business logic Modules modules layer has isolated independent parts with its own responsibilities main business logic is here here may appear apis, states, error handlers, validations, loading logic, etc... module can be big and difficult module contains all needed data and functionality inside to be independent from other modules modules do not interact with each other all logic is encapsulated inside a module and data to the outside should go via public apis index file Pages pages layer is like modules on upper level page may have own components, apis, helpers, etc... page should be as thin as possible ideally it should be just a list of modules and components as much business logic, helpers, states etc... should be extracted down into modules if possible if 2 modules to be grouped, we do it on a page level in real project it is not enough just to have pages , modules , components & ui more global folders will be introduced, like helpers , state , config , consts etc... Pros & cons + code isolation on module layer with public apis + one way data flow + reusability due to layers + modules are easy to modify & delete because pages are thin - not business oriented - not clear what goes to a component, what to a module - what do we do if one module should be used in other module, group logic on a page level, but what if we need it on different pages, then we have to duplicate it - where to keep business related entities like data, types & components for a product, an article, a user - unclear connections are formed in global folders like store, helpers, consts Modular architecture is a way better than classical, but does not fit well for a project with complex business logic and big variety of features Atomic design similar to modular architecture more design oriented was popular 4 years ago Atomic vs modular design Atoms Molecules Organisms Templates Pages Feature sliced design https://feature-sliced.design/docs/get-started/overview in FSD, a project consists of layers , slices and segments layers are vertically arranged layers are common across all projects ❗️ code on one layer can only interact with code from the layers below Example Shared layer reusable common functionality e.g. UIKit, libs, API ❗️No business logic here Entities layer (opt) elements which have a business value e.g. BlogPost, User, Order, Product can include a ui components with slots for content/interactive elements should contain the logic to describe how entity looks and behaves e.g. static UI elements, data stores, CRUD operations, reducers, selectors, mappers Features layer (opt) entity can act differently depending on features we apply to it feature is an action on entity to achieve a valuable outcome e.g. create-blog-post, login-by-auth, edit-account, publish-video, show-ad, grant-access, show-contact-information may contain interactive UI elements, internal state and API calls that enable value-producing actions Widgets layer compositional layer to combine lower-level units from entities + features into meaningful assembled blocks with content and interactive buttons wired to the api calls e.g. PostCard, IssuesList, UserProfile in this layer we fill slots left in the UI of Entities with other Entities and interactive elements from Features usually non-business logic come here (e.g. gestures, keyboard interaction, etc) for reach widgets business logic is permitted ❗️ it might be hard to decide what goes into Entities and Features. Do not worry. Just put all logic into Widgets layer. You will feel later if it should be split into Entities and Features Pages layer compositional layer to construct full pages / views / routes ❗️ no business and minimum other logic here App layer app-wide settings e.g. styles, providers, router, store Slices a layer can be divided into business oriented slices to keep related code together it is the same as a module in modular design described above e.g. post, add-user-to-friends, news-feed... shared and app layers never have slices as they do not have business logic inside ❗️ slices cannot use other slices on the same layer Closely related slices can be grouped in a folder, but they still should follow rule above ❗️ slices (and segments without slices) must contain the index file entry points (public API) with module re-exports code outside can not reference internal slice file structure, but public API only Segments a slice consists of segments to separate code by its technical nature, common segments, ❗️ but not necessarily are ui ui-logic, components model business logic, store, actions, selectors lib utils, helpers, hooks api communication with external APIs, backend API methods