Skip to main content

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

  • Also includes splitting the structure by business domains ("layers" and "slices")

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 libraries
  • api - the logic of interaction with the API
  • config - 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/ #

See also

[01/12] logo-mini