Clean Architechture.
Table of contents:
- A story of his past.
- General introduction about Clean Architechture.
- How is Android implements Clean Architechture?
- Apply Clean Architechture to a specific Android application.
- Pros and cons, compare it with MVVM, MVP.
Today I would like to write the rest. Those who have not read part 1 can review it here .
3. How is Android implements Clean Architechture?
_ Android will implement Clean Architechture as shown below: 
* See the picture we can see:
_ The application will be divided into 3 layers (ie 3 circles): Presentation, Data, Domain.
_ Dependency dimension: Presentation will depend on Domain, Data will depend on Domain. So the Domain will be the floor closest to the center of the circle, Presentation and Data will be two circles with the same radius and cover outside the Domain. Now we have the following dependent table: 
So we can see that only when the code at the Domain layer changes will our application be affected. And the code at the other two floors, no matter how much change, our application is still not affected. And fortunately if we recall the general theory of Clean Architechture, the Domain layer is little or almost never changing. So what does the directory tree on these levels look like: 
This is how to organize an Android application according to Clean Architecture. With this organization, it perfectly meets the required Architechture: Extend, Maintain, Unit-test. I will try to present in detail the picture above and the practical application I encounter problems that are solved by Clean Architechture (note the problems I present below I default readers of this article. already have knowledge and understanding of some Design Partterns like Repository pattern, Dependency Injection, Singleton pattern, because Clean Architechture uses these Design Patterns to make the application really “ Clean ”):
- Presentation Layer: This is the layer that users will see and interact with the application. The task of this layer is to execute the Usecases at the Domain layer in ViewModel or Presenter to get data and use the Android Framework to draw the views displayed for the user to see. (Note that when executing the Usecases in ViewModel or Presenter, we just wait for the callback to return data, but do not implement details on how to get that data, this is done at the Data layer.)
- Domain Layer: This layer is understood as the core, the core of the application. This layer contains 100% pure Java or Kotlin code, there is never an Android Framework present at this level. This is the most important layer of an Android application because the entire business logic will be here through usecases. Without the Presentation layer, can our application run? The answer is yes, you can keep this Domain module running on another IDEA other than Android Studio, but it can be IntelliJ, NetBeans … because this layer is simply Java or pure Kotlin. The task of this layer will execute the Usecases and get the data at the Data layer and return it to the Presentation layer.
- Data layer: This is the place to gather all the data of the application (maybe data retrieved from API, data of db local, data of SharePreference …). The task of this layer is to implement details on how to retrieve data and return to the Domain layer.
* A few questions are posed and applied in practice:
_ Why does each floor have its own model? => Because the Model at each tier is different, the Data tier model is only responsible for parseing data when making API calls or querying the DB. The model at the Domain layer only has the fields that the view needs. The model of the Presentation layer, if nothing special, is the Domain layer model. In fact, when working, we often encounter the case of dev 1 UI but do not have api to attach data. So after the api, the next thing to do is to modify at the Data layer, write more parse model at the data layer and write more mapper class to convert the model of D to the domain model so it is finished. Have you asked why not use parse model of the data tier to display on the view because it also has fields to display on the view? => By doing so, you have violated the second law of dependence (using peer objects). Now Presentation has depended on Data.
_ How about dev adding new features? (Extend) => We start from the Domain layer, create a model for the feature -> create a usecase for the feature -> define a function to get data for the feature in the Repository -> into the Data implement method just defined in the Repository on the Domain layer -> move through the Presentation ineject usecase layer to the Viewmodel or Presenter to execute get data and update the view.
_ What about changing (Maintain)? => For example, one day your boss does not like to use Room Database anymore but requires the team to switch to Realm Database, do not like to use Retrofit to call API anymore but switch to Volley to call API…. In these cases what you need to fix is at the Data layer, go to DI to fix the initialization of these objects and then inject it into the Repository Impl.
_ What about Unit-Test? => We only need Unit-Test in 2 places as follows:
- Java or Kotlin files implement Repository at Domain layer: This will be unit-test that helps me check whether getting data from different sources of the app is correct (for example, does the call api result return as we expect it to, request The local DB data returns the result as desired.
- Domain-level usecases: The purpose of unit-testing at usecases is to test the logic of each usecase. When writing unit-tests for usecase, we often need to Mock the returned value of the Repository.
=> Through a few examples I listed, you can see that the code is almost only edited at the Data layer, but thanks to the Clean Architechture, when the Data changes the other 2 floors, we are still peaceful ^^.
4. Apply Clean Architechture to a specific Android application.
_ This is a project I wrote a demo of Clean Architechture, the application simply shows the User list and when clicking on each User will show their Reputation, the application I write is very close to the drawing above (included) unit-test demo): https://github.com/tranphuc1995/CleanArchitechtureDemo
5. Pros and cons, compare it with MVVM, MVP.
* Advantages:
_ Recalling the theory, by now we might have envisioned the saying “stratified application”. The final goal of Clean Architechture is to divide the application into multiple layers, each floor will contain the same purpose code together, but still ensure how when changing the code at each floor, the entire application still does not affect much.
_ Through the illustrative examples I have shown in the above, the Clean Architechture is clearly an architecture that helps us to “Maintain”, “Extend”, “Unit-Test”.
* Disadvantages:
_ For me, the Clean Architechture is an architecture without any disadvantages. If so, is it just not suitable for small projects because of too many classes implemented? The second thing that I find Clean Architechture is really hard to grasp and understand is for beginners, because I also mentioned above to understand Clean Architechture then force you to understand Dependency Injection. Dagger – which I find most of this framework extremely difficult to chew ^^). When you download any sample source code to Clean Architechture, you will almost always see DI in it. And I’m the guy who found out about Clean Architechture when I didn’t know anything about DI, so the advice for you is to master the DI first and learn about Clean Architechture.
* Compared to MVVM, MVP.
_ Some people will ask me to compare Clean Architechture with MVVM, MVP, I would like to pay that is not comparable, why? Because it’s very simple MVVM and MVP are not Architechture but only a Design Pattern. If you look at the drawing above, you will see that it is just a Design Pattern on the UI layer of the Clean Architechture. As for why MVVM and MVP are not Architechture, you can refer to here .
My presentation on Clean Architechture is going to stop here. See you in the following articles. Thanks for taking the time to read your article ^^