Clean Architecture ‎ in Android

Robert C. Martin, better known as Uncle Bob, is the author of books such as Clean Code and Clean Coder. So stay with me.
Over the past decade, various architectures have been defined and used to design a structure for software projects, some of which have been welcomed and some of which have not.
Some of these architectures such as:

Hexagonal or Ports and Adapters architecture introduced by Alistair Cockburn.
Onion Architecture by Jeffrey Palermo (Onion Architecture)
Screaming Architecture by Mr. Bob Martin himself

If we talk a little about the above architectures, it should be said that each of these architectures has a different implementation from the other, but they all have a purpose. It means reaching the modular principle of isolation! That is, the separation of different parts of a system, each of which has a specific and independent task and performs.

Uncle Bob tried to achieve a comprehensive architecture called Clean Architecture by combining all the common features of several well-known architectures, which can be used and implemented in all programming languages ​​and frameworks.

One of the common aspects of the above architectures is the two layers of Business Rules and Interfaces. That is, these two layers are present in all the above architectures.

If we are to say a little about the features of these architectures, we can summarize them as follows:

The first is the independence and non-dependence of this architecture on the firmware that you are going to use. Exactly the same point we said above. This architecture can be implemented in any framework. In fact, in this system, the architectures that are a tool are easily editable or replaceable, like a plugin.

Independence of UI and Database is another feature of this architecture. In these architectures, the UI can be changed without changing the logic or the same Business Rule. This is also true for databases, as the database can be switched from SQL Server to Oracle or Mongo and BigTable.

And one of the most important features is the independence and ignorance of the inner layer from the outer layers. That is, the Business layer is designed and implemented completely independently of other layers.

The software can be tested because the layers work independently and separately from each other, with techniques such as mocking, each layer can be tested independently of another layer.

Independence from any external resource. In this way, the layer that contains the business rules has no information about other layers.

As shown above:

Layer C has access to layers B and A.
Layer B knows everything in Layer A but has no knowledge of Layer C. In fact, it is not even aware of the existence of layer C.
Layer A is the lowest layer and has no information about other layers. In fact, it is a completely blind and blind layer.

This is the essence of the story. The rest of the details serve these three key principles.

In the following, you will see the general view of this architecture in the form of an image.

Dependency Rule:

To use this architecture, we need to be familiar with a principle called the Dependency Rule, which we’ll talk about a bit later.
As you can see in the image above, we are dealing with multiple layers. There are at least 3 layers, but depending on the scenario and its complexity, the number of layers can be increased.
This principle and law have been observed in all parts of these layers. In this way, the internal circles of software policies and more external circles include the mechanisms needed to implement those policies.
According to the principle of dependence, layers are from outer layers to inner layers. This means that an outer layer can use inner layers, but the opposite is not true. That is, the inner layers are not aware of the existence of the outer layers, so they do not have access to their facilities.

In the image below, we can better understand the concept that the layers are connected from outside to inside:

Note this image in relation to these relationships between layers:

Layer Entities

This layer contains business rules. Business rules can be implemented as objects, classes, or even data structures. This layer is the most resistant to change. That is, if there is a change in the outer layers, this layer will not change at all. This means that if a change is made in the UI, this part will remain unchanged.

Use Cases layer

This layer contains the implementation of software operations. That is, if we have an online store, we can have parts like

Order
Record personal information for profiles
Submit and send comments
…

Put in this layer. That is, if we study this layer, we will get a general knowledge of the software.

Interfaces and Adapters layer

This layer contains interfaces and adapters to convert one format to another. That means converting layer formats for each other. For example, converting the data format from the appropriate state for the entities and use cases to the appropriate format for the more external layers and vice versa are the tasks of this layer.

Frameworks and drivers layer

This layer is the most external and consists of Tools or tools and frameworks. Items such as databases and frameworks and the like are defined and implemented in this layer. That is, all the details of the system are in this layer. That is, databases, UIs, .. are the same details.

In each of these layers, we have to use different tools and components that if you pay attention to this image, you will understand to some extent:

In general, you can use the following technologies for this architecture in Android programming according to your needs and according to your organizational scenario and goal. You can use different sources to get acquainted with each of the following. They will only be introduced here.

Kotlin: A language for Android programming that is supported by Google and has many features and characteristics that distinguish it from its competitor for Android programming, namely Java. You can refer to the relevant documents for further reading.

Dagger 2: A framework for dependency injection in Android and Kathleen and Java programming

RxJava 2: A library for Reactive programming

Retrofit 2: A library for communicating with servers on Android

Room: A library for Android databases based on SQLite.

ViewModel: A library used to manage and store the user interface in an activity or fragment lifecycle way.

LiveData: A so-called observable data that again manages an activity or fragment of data according to the life cycle.

Paging Library: Makes it easier for us to load data gradually in RecyclerView.

As I said, you can use, delete, or change any of them according to your needs.

Well, I said the definition and explanation of this architecture, but if we are going to use this architecture in Android programming, we will discuss it in future posts.

Thanks for reading! And if you enjoyed it, gimme a clap

Sana Ebadi | 20:27 PM Thursday, 8 October 2020