Basics
caution
Only basic information on the methodology is presented here
For a more competent application, it is worth getting acquainted with each concept in more detail in the corresponding section of the documentation
Concepts
Public API
Each module must have a declaration of its public API at the top level
- To connect to other modules, without the need to refer to the internal structure of this module
- To isolate the implementation details from the consumer modules
- Also, the Public API should protect the module interface after refactoring - in order to avoid unforeseen consequences
Isolation
The module should not depend directly on other modules of the same layer or overlying layers
- The concept is also known as Low Coupling & High Cohesion - to prevent implicit connections / side effects during development and refactoring
Needs driven
Orientation to the needs of the business and the user
Abstractions
For architecture design the methodology suggests operating with familiar abstractions, but in a more consistent and consistent order.
Layers
The first level of abstraction is according to the scope of influence
app
- initializing the application (init, styles, providers,...)processes
- the business processes of the application control pages (payment, auth, ...)pages
application page (user-page, ...)features
- part of application functionality (auth-by-oauth, ...)entities
- the business entity (viewer, order, ...)shared
- reusable infrastructure code (UIKit, libs, API, ...)
Slices
The second level of abstraction is according to the business domain
The rules by which the code is divided into slices depend on the specific project and its business rules and are not determined by the methodology
Segments
The third level of abstraction is according to the purpose in the implementation
ui
- UI-representation of the module (components, widgets, canvas,...)model
- business logic of the module (store, effects/actions, hooks/contracts,...)lib
- auxiliary librariesapi
- the logic of interaction with the APIconfig
- the configuration module of the application and its environment
note
In most cases, it is recommended to place api
and config
only in the shared layer
Structure
โโโ src/
โโโ app/ # Layer: Application
| #
โโโ processes/ # Layer: Processes (optional)
| โโโ {some-process}/ # Slice: (e.g. CartPayment process)
| | โโโ lib/ # Segment: Infrastructure-logic (helpers/utils)
| | โโโ model/ # Segment: Business Logic
| ... #
| #
โโโ pages/ # Layer: Pages
| โโโ {some-page}/ # Slice: (e.g. ProfilePage page)
| | โโโ lib/ # Segment: Infrastructure-logic (helpers/utils)
| | โโโ model/ # Segment: Business Logic
| | โโโ ui/ # Segment: UI logic
| ... #
| #
โโโ widgets/ # Layer: Widgets
โโโ {some-widget}/ # Slice: (e.g. Header widget)
| | โโโ lib/ # Segment: Infrastructure-logic (helpers/utils)
| | โโโ model/ # Segment: Business Logic
| | โโโ ui/ # Segment: UI logic
โโโ features/ # Layer: Features
| โโโ {some-feature}/ # Slice: (e.g. AuthByPhone feature)
| | โโโ lib/ # Segment: Infrastructure-logic (helpers/utils)
| | โโโ model/ # Segment: Business Logic
| | โโโ ui/ # Segment: UI logic
| ... #
| #
โโโ entities/ # Layer: Business Entities
| โโโ {some-entity}/ # Slice: (e.g. entity User)
| | โโโ lib/ # Segment: Infrastructure-logic (helpers/utils)
| | โโโ model/ # Segment: Business Logic
| | โโโ ui/ # Segment: UI logic
| ... #
| #
โโโ shared/ # Layer: Reused resources
| โโโ api/ # Segment: Logic of API requests
| โโโ config/ # Segment: Application configuration
| โโโ lib/ # Segment: Infrastructure-application logic
| โโโ ui/ # Segment: UIKit of the application
| ... #
| #
โโโ index.tsx/ #