P2: Clean Architecture in Android and examples

Tram Ho

The previous article I presented an overview of Clean Architecure . The idea of ​​Clean Architecture is to be able to meet the criteria:

  • Independent of Frameworks
  • Testable
  • Independent of UI
  • Independent of Database
  • Independent of any external agency

And we don’t necessarily have to use all 4 layer circles. We only need to view it as a follow-up diagram, but one thing to keep in mind is the Dependency Rule.

The inner layer shouldn’t know anything about the outer layer. Basically, this rule says that no matter what the outer layer’s data format will not affect the inner layer, or changing the business rule in the inner layer will not affect the display in the outer layer.

Following the idea of ​​Clean Architecture, we need to separate the layers, such as domain, storage, and presentation. However, Clean Architecture has no restrictions on defining layers correctly. We can use the number of layers to suit our needs.

I have consulted some sources, then the people often divided into 3 layers: domain, data, presentation . Because the demo example is also simple, I will also divide the project into 3 layers:

Due to the picture I copied online, but the demo I’m using MVVM so people should understand Presenters here is ViewModels if using MVVM.

  • The view does not contain any business logic but only interacts with the ViewModel
  • ViewModel does not contain any business logic and only interacts with Domain layers through Use cases (or sometimes I see people call it Interactors ).
  • Domain layer contains business logic, the main Entities are models (usually POJOs or can also be objects with some logic or validation logic), data class, interfaces. Use cases class is where business logic is represented, each use case should be limited to one feature (follow Single Responsibility Principle ). Use cases act as a middle-man between the Presentation layer and the Data layer but don’t know anything about the other two layers thanks to the virtue of Inversion of Control (Google translate is: the reverse of control. I left the original in English).
  • Data layer will implement Domain layer abstractions. The goal is to isolate the Data layer from the Presentation layer so we can easily change it as needed. For example, the project is using the Room database in the Data layer, we can change another database easily. In general storing, fetching data or request network operations we will perform here.
  • Presentation layer contains things related to UI and Android such as view architecture (MVP, MVVM …), fragment, activity, …

Separating layers using the Gradle module makes the code easy to read, maintain, extend and test.

I. Multi-Project Gradle setup

The project example includes 3 Gradle modules:

  • data – Android library module

  • domain – Java library module

II. Example step by step

My code did not add here to avoid distractions. Everyone follow Github .

Problem : Note text application. Use:

Project structure:

1. Domain layer

Packages: model -> repository -> usecase :

  • Note.kt : It is simply a normal object to have validation logic.
  • NoteRepository & NoteModelMapper : is a Domain layer abstractions, providing access data methods. In the Data layer will implement this interface.
  • AddNoteUseCase & GetNotesUseCase : These are the use case of the system, “middle-man between Presentation layer and Data layer”.

2. Data layer

Packages / class: model -> local.db -> impl

3. Presentation

At this layer, everyone will be familiar with it, here we can use MVP, MVVM models as usual. As mentioned above, this layer will use usecase on the domain layer as a middle man of the Presentation layer and Data layer. package:

And the end is the result.

This share is based on my own understanding so it is impossible to avoid omissions and incorrect points. Look forward to comments and help from everyone. Reference source: https://proandroiddev.com/kotlin-clean-architecture-1ad42fcd97fa

Share the news now

Source : Viblo