Simplifying Android Architectures for Developers — MVC, MVP, MVVM, Clean, MVI, VIPER — part 4: Clean

3 min readSep 20, 2022

Clean Architecture

Theory

Yes, I will talk about other architecture that split our classes by layers. We will have 3 groups: Presentation, Domain, Data

First of all, these concepts have to be flexible and adapted to be applied in your project. Probably you will find projects where the connector represented by the Presenter Layer on this Clean Diagram is a Controller, Presenter, or ViewModel. Then your project can follow Clean + (MVC, MVP, MVVM, …)

Let's focus on the Domain and Data layers and after done, I will apply that to each architecture.

Domain

Contains the business logic and interfaces to be implemented by the Data layer.

Inside the Domain layer we have 3 more layers:

Models: contains entity models

Repository: contains an interface to represent all inputs and outputs of your data provider.

UseCases: Contains all kinds of interactions that this data provider could have.

Data

Contains implementations of data providers.

Inside the Domain layer we have 3 more layers:

Models: Maybe you will find applications, where a model found from an API service, is different from what the application expects for work. So, here will be that kind of data representation.

Repository: Here will be your provider application implementation. Could be an API Rest, Database, or SharedPreferences that implements the interface in Domain > Repository.

Mapper: Basically, it converts the format received by the provider to the format expected by the application or the inverse.

Practice

I will show the implementation of the common part (Data and Domain) before showing the Presenter Layer that will be according to our architecture: MVC, MVP, MVVM

Check how became our project structure:

Domain

domain>models >Person.kt

You already know this class from our previous samples. It was moved to another directory.

domain>repository>PersonRepoContract.kt

You already know this class from our previous samples. It was renamed and moved to another directory (I named it before as PersonModelContract).

domain>usercases>GetPersonUseCase.kt

domain>usercases>UpdatePersonUseCase.kt

Note: Use cases keep depending on the abstraction of our repository

Data

data>models>PersonDataModel.kt

Note: PersonDataModel has the same structure as Person. But it could be different, and it could be a strong justification to use this approach and to use a mapper.

data>models>PersonMapper.kt

data>repositories>PersonRepository.kt

You already know this class from our previous samples. It was renamed and moved to another directory (I named it before as PersonModel).

Presentation

I'm talking about the Presentation layer defined in the Clean Architecture. But as I said, it could assume other types of connectors like Controller, Presenter, or ViewModel defined by other architectures. Do not confound the Presentation layer of Clean Architecture with the Presenter Layer of MVP.

You already know these classes. The main change is that stopped using directly the data provider. Now I am requesting information from use cases.

MVC

If you didn't see the article about MVC, I recommend you see it here

MVP

If you didn’t see the article about MVP, I recommend you see it here

MVVM

If you didn’t see the article about MVVM, I recommend you see it here

You can check this project on GitHub. Remember to select the architecture that you wish to study on the build variants: