|
| 1 | +# Architecture overview |
| 2 | + |
| 3 | +{app_name} project code built on Clean based hybrid Architecture (I'll just call it Clean architecture for simplicity's sake). |
| 4 | + |
| 5 | +The main concept of regular [Clean Architecture](http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html) is codes splitted to layers, where every low-level layer knows nothing about up layers, separation of business logic from UI, not depending on frameworks or libraries, etc. |
| 6 | + |
| 7 | +The architecture we used in {app_name} project is very similar to the regular Clean architecture, but it has its own values, which is why we call it Clean based quasi-architecture. |
| 8 | + |
| 9 | +The main features of the architecture: |
| 10 | + |
| 11 | +* a clear separation of code into layers: data, domain, presentation is preserved; |
| 12 | +* each layer operates with data within its responsibility; |
| 13 | +* interaction between layers occurs through interfaces; |
| 14 | +* data models are separated from general use models; |
| 15 | +* DI is used to provide access to code components; |
| 16 | +* the chain of access to components and method calls is strictly defined and cannot be broken; |
| 17 | +* there is an additional app layer to meet the needs of the application; |
| 18 | + |
| 19 | +## Layers, components, and their interaction |
| 20 | + |
| 21 | +### App level |
| 22 | +Contains classes that meet the needs of the entire application. These are usually global components that affect the operation of the entire application. For example: navigation components, localization, utilities, etc. |
| 23 | +This layer also contains application-level services. Usually, these are services that process and store data on which the application globally depends. For example: authorization status, current user profile, etc. |
| 24 | +These services are created and transferred using DI. |
| 25 | + |
| 26 | +### Data layer |
| 27 | +The data layer operates with the lowest-level data and deals with receiving data from various sources, transferring data to storage locations, transforming it, organizing it, and then transferring it to the next layer. |
| 28 | +To be more specific, the main operations that take place in the data layer are as follows: |
| 29 | + |
| 30 | +* work with APIs; |
| 31 | +* work with data storage; |
| 32 | +* work with other data providers; |
| 33 | +* data transformation for further use in other layers; |
| 34 | + |
| 35 | +The data layer has 2 main components: **source** and **repository implementation**. |
| 36 | + |
| 37 | +**Source** receives data directly from the provider: API, Storage, or others data providers and transmits it in the data format or class of a specific error. |
| 38 | + |
| 39 | +The **repository** interacts with different sources, receives data from them, transforms, combines and performs other necessary operations and passes it on in the format of data or error. |
| 40 | + |
| 41 | +Both components are created through DI, and have a dependency between them, so that **source can be called from repository but not vice versa**. The dependency is ensured by passing source to the repository constructor (in the DI configuration). |
| 42 | + |
| 43 | +### Domain layer |
| 44 | +The Domain layer is the link layer between data and presentation. In this layer, data is retrieved from the data layer and data calls are organized into specific scenarios. |
| 45 | + |
| 46 | +The main components are: **usecase** and **repository interface**. |
| 47 | + |
| 48 | +**Usecase** executes specific scenarios in the application by calling repositories, services, and other auxiliary components and returns a result that is ready to be used in the presentation in the format of data or error. |
| 49 | + |
| 50 | +The **repository interface** is a simple interface that describes the functions of a specific repository and from which a specific repository in the data layer is inherited. |
| 51 | + |
| 52 | +Both components are created through DI and have a dependency between them, so that **usecase can call functions of repository (or service) but not vice versa**. The dependency is ensured by passing source to the repository constructor (in the DI configuration). |
| 53 | + |
| 54 | +### Presentation layer |
| 55 | +The presentation layer contains classes that are responsible for the visual display of the application, UI and screens, as well as **state controllers and presentation logic holders**(BLoC). |
| 56 | + |
| 57 | +Usually, a separate state controller is used for each screen. But there are cases when it can be used in several places. |
| 58 | + |
| 59 | +The **state controller** is the highest component in the call chain by calling **usecase** and it initiates calls to other components sequentially. In turn, the state controller depends on the events that occur in the UI. |
| 60 | + |
| 61 | +### Call chain |
| 62 | + |
| 63 | +To be more specific, the call chain works from the highest level (UI and state controller) to the lowest and usually looks like this: |
| 64 | + |
| 65 | +* usecase called from state controller (BLoC); |
| 66 | +* one or more repositories(interface) (or services) called from usecase; |
| 67 | +* one or more sources called from repository(implementation); |
| 68 | +* source called data provider (API request or else); |
| 69 | +* result is providing back to caller by returning result in each component; |
| 70 | + |
| 71 | + |
| 72 | + |
| 73 | + |
| 74 | + |
| 75 | + |
0 commit comments