# Android Architecture
## Intro

Project architecture based on CLEAN architecture with feature based package structure. This approach helps to retain code consistency for a large code base and provides ability for splitting up project in modules.

## Layer structure
Code consists of 6 layers:
- Cache
- Remote
- Data
- Domain
- Presentation
- View

The dependency structure is following:


For now all layers lay down in the same gradle module but there are plans to **split them between distinct gradle modules** after code migration will be finished.

In code each layer represented by root package.


### Feature by package
Layers package consists basically consists of `base` package with some base code and feature packages along with some layer specific packages. `base` package should have **the same structure** as the feature packages of this level.

Feature package of current level can depend on another feature packages of this level and on feature packages of levels that current level depends on.

Example:

class CourseInteractor
@Inject
constructor(
    CourseRepository, // course feature package
    LessonRepository  // lesson feature package of domain level
)

### Models and mappers
You'll see a lot of models and mappers in this architecture but you shouldn't use all of them if you don't need to. For example if you have object like this

class Data(
    @SerializedName("name")
    val name: String
)

that came from API in the same way, can be stored to db without changes and passed to view you can declare it in domain layer and skip all mappers and models on other layers.

## Layers
### Cache

Cache layer contains everything you need to work with local db storage. All packages are optional as the layer itself. So you should not create cache level for feature with no caching logic and in the same way you don't need to create mapper package or model package if data layer model can be stored without changes.


#### CacheDataSource
Cache data source implementation connects `cache` layer with `data` layer.

Naming convention: feature name + `CacheDataSourceImpl` suffix
Example: `VideoCacheDataSourceImpl`

#### dao
Package with dao implementations for each object.

Naming convention: object name + `EntityDao` suffix
Example: `VideoEntityDao`

#### mapper
Package with mappers to map from data layer models to cache models

Naming convention: object name + `EntityMapper` suffix
Example: `VideoEntityMapper`, `CourseEntityMapper`

#### model
Package with pojo classes that represents database entities.

Naming convention: object name + `Entity` suffix
Example: `VideoEntity`, `VideoUrlEntity`, `CourseEntity`

#### structure
Package with table schemes constants

Naming convention: object name + `DbScheme`

#### Dependency map

### Remote
In global context remote layer serves the similar role to cache layer -- it's another data source. `remote` package has the same structure with feature base package and `base` package.


#### RemoteDataSource
Remote data source implementation connects `remote` layer with `data` layer.

Naming convention: feature name + `RemoteDataSourceImpl` suffix
Example: `VideoRemoteDataSourceImpl`

#### mapper
Package with mappers to map from remote models to data layer models

Naming convention: object name + `Mapper` suffix
Example: `VideoMapper`, `CourseMapper`

#### model
Package with pojo classes that represents request structures and will be parsed with gson.

Naming convention: object name + `Request`/`Response` suffix
Example: `CourseRequest`, `EnrolmentRequest`, `CourseResponse`

#### service
Package with retrofit services interfaces.

Naming convention: feature name + `Service` suffix
Example: `EnrolmentService`

#### Dependency map

### Data
Main goal of data layer is to manages data within available sources.


#### mapper
Package with mappers to map from data models to domain layer models

Naming convention: object name + `Mapper` suffix
Example: `VideoMapper`, `CourseMapper`

#### model
Package with pojo classes that represents data layer models.

Naming convention: object name
Example: `Course`, `Enrolment`

#### repository
Package with repositories interfaces implementations. Repository contains logic that manages data between sources.

Naming convention: feature name + `RepositoryImpl` suffix
Example: `CourseRepositoryImpl`

#### source
Package with source interfaces.

Naming convention: feature name + source type + `DataSource` suffix
Example: `CourseRemoteDataSource`, `CourseCacheDataSource`

#### Dependency map

### Domain
Domain layer contains all business logic of application.


#### exception
Package with bussiness logic exceptions. Those exceptions could be thrown from `domain`, `data` or sources levels and should be handled in `presentation` level.

Naming convention: case name + `Exception` suffix
Example: `NotAuthorizedException`

#### interactor
Package with bussiness logic. Interactor should unite common case logic. Interactor could be splat up in disctinct interactors that carries less logic.

Naming convention: case name + `Interactor` suffix
Example: `CourseInteractor`, `CourseEnrolmentInteractor`, `CourseBillingInterctor`

#### mapper
Package with mappers to map data from another domain packages.

Naming convention: target object name + `Mapper` suffix
Example: `CourseContentMapper`, `CourseInfoMapper`

#### model
Package with pojo classes that represents domain layer models.

Naming convention: object name
Example: `CourseContent`, `CourseInfo`, `EnrolmentStatus`

#### repository
Package with repositories interfaces.

Naming convention: object name + `Repository` suffix
Example: `CourseRepository`

#### resolver
Package with different resolvers and helpers in order to simplify interactors in some cases.

Naming convention: case name + `Resolver` suffix
Example: `DeadlinesResolver`

#### Dependency map

### Presentation
Presentation layer connects `view` level with `domain` level and manages view states.


#### mapper
Package with mappers to map data from domain or presentation layers. This can be useful to map view states.

Naming convention: target object name + `Mapper` suffix
Example: `CourseContentItemsMapper`

#### model
Package with pojo classes that represents models which is used in view states.

Naming convention: object name
Example: `DeadlineState`

#### Presenter
Presenter that manages current view state and fetches data from interactors.

Naming convention: feature name + `Presenter` suffix
Example: `CoursePresenter`

#### View
View contract.

Naming convention: feature name + `View` suffix
Example: `CourseView`

#### Dependency map

### View
View is the last layer in this architecture which consists of platform related implementations of displaying content. In global terms this layer characterize application. Along with view implementations it contains DI components needed to build application.


#### injection
Injection package contains everything related to dependency injection as components, modules and scopes. It structured in the same way as layer package with `base` package and **feature packages**. Usually feature package consists of:
- `FeautureNameDataModule` -- module that provides data layer of feature (if exists) with repository implementation
- `FeatureNameModule` -- module with presenters bindings and other feauture related components
- `FeatureNameRoutingModule` -- module with feature specific routers
- `FeatureNameScope` -- scope of feauture if needed
- `FeatureNameComponent` -- component of feauture if needed

Usually there are a lot of features that have only `FeatureNameDataModule` that is included in another components.

#### mapper
Package with mappers to map data from domain or presentation layers to view level models.

Naming convention: target object name + `Mapper` suffix
Example: `CourseContentItemsMapper`

#### model
Package with pojo classes that represents models which is used in views, like `RecyclerView` adapter items and etc.

Naming convention: object name
Example: `DeadlineState`

#### routing
Package with routers specific to current feature, like `branch` routers or deeplink routers.

Naming convention: feature name + case name + `Router`
Example: `CourseDeeplinkRouter`

:::info
TBD
:::

#### ui
Package with everything related to ui like activities, fragments, adapters, delegates, views etc.

#### Dependency map

## Where should I put that code?
If after reading the previous paragraph you still have question: "Where should I put that code?" just keep in mind that code structure should be easy splittable by layers and by features.


As can be seen from this diagram code base is easy splittable and each code block can be extended to distinct gradle module and be **reused** in different target or application. Dashed arrows means optional dependencies.

## All elements dependency map