Clean Architecture com MVVM: what it is, its advantages, and how to use it in Android applications

Over the years, complex Android applications have been created using several existing architectures such as Model-View-Controller, Model-View-Presenter, and Model-View-ViewModel. The emergence of Clean Architecture by one of the biggest influencers in the global development community, Robert C. Martin, also known as Uncle Bob, author of a book on this topic, contributed to creating an architecture in which the components were decoupled, testable, and easy to maintain.

What is Clean Architecture?

The Clean Architecture consists of a layer diagram. Each of its components has its responsibilities. Each of them is only aware of the layers inside; that is, the “Frameworks and Drivers” layer only sees the “Interface Adapters” and so on.

VaAdvantages of using Clean Architecture

• O código é facilmente testável, se comparado a arquitetura MVVM simples;
• Componentes ainda mais desacoplados, a estrutura do pacote é facilmente de se navegar entre e
• The code is easily testable compared to simple MVVM architecture;
• Even more decoupled components, the package structure is easy to navigate between them;
• The developer team can quickly add new features.

  Disadvantages of using Clean Architecture

• A relatively steep learning curve, considering that all layers work together, requiring some time to understand their concepts, especially for developers coming from standards such as MVVM and simple MVP;

• Because the architecture requires the addition of many additional classes, this model is not ideal for low-complexity projects.

The intention is to demonstrate the rules of dependency inside the architeture.

Entities

The central concept is that this layer should contain everything pertinent to the system in terms of business logic in the most generic way possible, less likely to change when there are external changes. This layer contains the object models used for business logic, such as POJOs (Plain Old Java Object) and Data Class in Kotlin.

Use Cases

The most specific business rules of the system are located in this layer, and it is also the place where it will be verified how the presentation layer will receive the data.

Interface Adapters

This layer is responsible for performing the data conversion to be as accessible and convenient as possible for the Entities and Use Cases layers.

For example, input data is captured in a user interface and conveniently packaged for use cases and entities. It then retrieves the output data from the use cases and entities. It packages them into a convenient format for displaying in the user interface or saving them to a database.

Frameworks

The outermost layer is usually a database, web, user interface, etc. This layer must have as little code as possible, and it is necessary to interconnect the layers and interfere as little as possible.

AMVVM layers with Clean Architecture on Android

Using this architecture in Android applications, which is a combination of MVVM and Clean Architecture, the codes are divided into three distinct layers:

Presentation Layer:

In this layer, the “Activity”s are included, “Fragment”s being the “Views,” and the “ViewModel”s; they should be as intuitive and straightforward as possible. Business rules should not be included in the “Activity” s and “Fragment”s.

A “View” will communicate with its respective “ViewModel,” and thus, the “ViewModel” will communicate with the domain layer so that specific actions are performed. A “ViewModel” will never communicate directly with the data layer;

Domain Layer:

In the domain layer, they must contain all the application’s use cases. Use cases are intended to be mediators between your “ViewModel”s and the “Repository”s.

If you need to add new functionality, all you have to do is add a new use case, and all your code will be completely separate and decoupled from the other use cases. The creation of a new use case is precisely to avoid that when adding new features, breaking existing ones in the code;

Data Layer:

This layer has all the repositories that the domain layer has available for use and “DataSource”s, which are responsible for deciding which source the data should be retrieved from, whether from a local database or a remote server.

The communication flow between the layers can be illustrated according to the following diagram:

O propósito não é mostrar qual arquitetura é ideal para todas as aplicações, mas apresentar uma

The purpose is not to show which architecture is ideal for all applications but to present an architecture that is more scalable, testable, and easy to maintain for more complex projects.

Although it is an architecture with a high degree of learning in the implementation, it becomes a solution of excellent viability in the long term to carry out its maintenance and tests; the Clean Architecture, according to my experience with mobile development, is a solution with great feasibility in projects of greater complexity.