In this article, I will share my experience of structuring projects, which I have been successfully using for three years in my projects. I think that structuring a project by file types is not the best approach, although it works well in some situations. My team and I use something similar to modular architecture for our projects, and we want to share it with you! React Native 🚩 Problem There are several approaches to creating the structure of client applications. The most common, but not the most convenient one, is splitting the project by file type. is that the logic of one module is "smeared" over the whole project. In this approach, the structure usually looks like this: The main problem api components containers - HomeContainer.tsx - ProfileContainer.tsx - SettingsContainer.tsx store App.jsx 🙌🏻 Solution More convenient and scalable is the approach of dividing the project by functionality. We call such top-level units, into which the project is divided, modules. src - modules - - auth - - core - - users - - navigation - - ud-ui When divided into modules, all components and logic are next to each other. It is easier to work with such a project: it is to navigate the structure, delete and refactor modules, it is easier to see the overall picture of functionality, and there is less chance of interfering with each other during development. Functionality does not always mean business logic. There are functional modules, such as core, ud-ui, which are not tied to business logic. easier Module Structure: Domain ( - Business logic of the module) An instrument in the hands of a conductor Store ( - Module control logic) Conductor UI ( ) Presentation 🪄 Domain lvl Typically, this layer contains interfaces, model descriptions, services to query the API, or business logic that is not related to a specific view (UI) Structure of the Domain layer domain - enums - - UserRoleEnum.ts - interfaces - - User.ts - repositories - - UserRepository.ts - resources - - UserResource.ts What can be stored at the Domain level? Enums Interfaces Services Helpers Resources and Repositories (API) 💾 Store lvl This layer is where the application is managed and interacts with the layer for and changes to the . Example of Store-level structure using Domain API calls Store Redux-Toolkit: store - entities - - index.ts - - selectors.ts - - actions.ts - detail - - ... - edit - - ... - other-stores - - ... - reducer.ts - selectors.ts Entities Store Usually, a separate store called “entities” is used to . This is a kind of for the client application to store entities of the same type. The other stores use identifiers if you need an entity that has already been loaded. So, if an entity is changed, it is changed in one place - entities store, and the rest of the program picks up the changes because it actually uses a reference to one common object. store data database Other stores Usually refers to individual pages or time-consuming actions, for example: - user edit page edit - user list page index - user creation page new 🖼️ UI lvl The UI layer contains elements related to data presentation, such as , , and . Usually, the layer is divided as follows: components screens hooks ui - screens - - profile - - - index.tsx - - - style.ts - - login - - - ... - components - - users-list - - - index.tsx - - - style.ts - - create-user-modal - - - ... - hooks - - useUserForm.ts - - ... Screens This folder contains components that are directly assigned in routing, i.e., they are screens or pages in the navigation structure of the application. Components Components that relate to the module's business logic. Can be used outside the module but are necessarily inside its structure Divide and rule!