Clean Code Architecture

In 2017, Google officially recommended app architecture using Architecture Components for Android applications. Architecture Components has made developers’ life easier, as it is simple, flexible, and practical. As a result, developers can focus on writing modular apps with less boilerplate code.

Expectations from a modern app architecture:

It needs to be robust, stable, quick, adaptable, and extendable, and should supports testability. In addition, it should be practical enough to be understood by different levels of developers in order to maintain the app.

I believe Clean Architecture suffices all the expectations.

The goal of this article is to provide a step-by-step guidance for developing Android apps in a better and cleaner way.

Layers of Clean Code Architecture

In the Clean Architecture, the code is separated into multiple layers (see figure below [source: Clean Architecture by Robert C. Martin]). The inner layers contain business logic, the outer layers contain implementation, and the middle layer contain interface adapters. For a robust app architecture, the code should be separated in a way that inner layers don’t know anything about the outer layers; meaning that the dependencies should point inwards (The Dependency Rule).

For a better and more extensive explanation on the Clean Architecture, refer to the official article or the official video.

How to represent these layers in the app:

Salient Features of Clean Code Architecture:

• Decoupled and easy to maintain: as the layers are independent. Every layer has its own model that it works with, so the concrete details, such as views, do not depend on the specific details of the lower layer implementations.
• Easy to test: your code is easily testable compared to other architectures.
• Very cohesive: as it is easy to navigate. Each of inner layers can transform the data in a way the outer layer can understand it.
• It incorporates and satisfies SOLID Principles.
• It is “frontend” agnostic — meaning we can use MVP, MVVM or anything else on top of it.
• It fulfils the Extendability requirements, as the codebase doesn’t require changes each time a change is implemented in the outer layer.
• It is time consuming to start with, but that outweighs the maintenance efforts required down the line, as the coding is robust and would require minimal maintenance activities.

Let’s start with example 👩🏻‍💻👨🏻‍💻

1. CustomerView

2. CustomerPresenter

3. CustomerUsecase & Interactor

4. CustomerRepo

4. CustomerEndPoint

4. CustomerDetailResponse

What about test ? 🤓

1. CustomerPresenterTest

2. CustomerInteractorTest

3. CustomerRepoTest

Conclusion

Working on Clean Code Architecture proved beneficial to our team in terms of testing and maintaining the application over a longer period of time. All salient features mentioned above were experienced first hand and we were able to distinguish the advantages compared to other architectures we used in the past.

In conclusion, as a developer, I would recommend the Clean Code Architecture over any other architectures.

I hope you find this article helpful and will appreciate your feedback, if any.