Architecture

Domain

The Domain module is a Java/Kotlin library and does not have Android context. This module is used to define the business aspect of your application: data models, use cases and interfaces of our Repositories. It's not aware of data and presentation modules and does not depend on any module.

• Model: Kotlin data class so that the object is immutable. No dependencies such as parsing (GSON) or database (Room) annotations are needed to detach these models from everything else.

• UseCase: These objects allow you to execute specific business actions. Business logic should be here. The way or the technology you'll use will be defined in the implementation of your repositories.
  For example GetListRepo: if I am connected I fetch data from the web service, then I save it in cache and I return it from cache. If I am not connected I return the cached data. If there is no data in cache I return an error to prevent that the user is not connected.

• Repository: These are the DataRepository interfaces which will be implemented in data module. It's defined here to be used by use cases. It includes all possible data manipulation actions.

👀 You can check the domain module here: domain

Data

The data module is defined as an Android library in your project. You can find the following packages:

• Net: It allows you to manage consumption of your web services. In this example we use Retrofit and GSON. It is therefore necessary to define all the DTOs which represent data classes of web service responses with GSON annotations.

• Persistence: It allows you to manage the way you want to backup data in your application. In this example we use Room. Just like DTOs we must also define the Entities of all the objects that we will save in DB.

• Mapper: It allows you to transform your DTO into a Model and your Model into an Entity.

• DataRepository: This class is the most important of the whole module. Here, we will define the technical logic of how we manipulate data with the set of classes that we have just seen. If we choose to change the technical behavior (change library to consume web services for example) all the logic will be found in this class and won't allow editing the rest of our application.

👀 You can check the data module here: data

Presentation

The goal of the presentation module is to display and manage views of your application. This is your main module: application module. It communicates with the data and domain modules.
This module mainly contains what are called scenes: it represents each screen of your application. In this architecture we use MVI (Model View Intent) for each scene.

👀 You can check the data presentation here: presentation

Each scene is composed of:

• Activity: mostly contains a toolbar and a container to display a fragment.
• Fragment: contains the content of our screen. Each scene contains a fragment in order to easily manage a future tablet version if necessary. It is not mandatory but rather recommended.
• View: interface with all the intents (interactions) available in our scene and a render function for sending a ViewModel to our scene.
• ViewModel: it represents the state of our screen.
• Presenter: it is attached to our view and will be able to listen to different actions, handle it and return the state of our screen as ViewModel.

In this architecture, Fragment inherits from View and implements each action as Rx events. Then we attach the Presenter to the View to start listening to the interactions. Finally, we implement the render function which will be called by our presenter to return the state of our screen.
MVI is very similar to MVP but its biggest advantage is that it contains only one entry point. We call our Presenter only once to attach to it. This detail greatly facilitates unit and UI testing.

👀 You can check a sample of scene here: repo scene