Text posts are Android Clean Architecture but P1 I have not said anything. P2 I will share about Android Clean Architecture and the following implementations. Due to the relatively long content, this article I just briefly outline the concept of Clean Architecture and layers.
What is Clean Architecture?
Clean Architecture, also known as clean architecture, was proposed in 2012 by Robert C. Martin. You can refer to the details in The Clean Code Blog by Robert C. Martin (Uncle Bob)
Which describes a Clean architecture as an architecture that meets the following criteria:
- Independent of Frameworks: Each framework always has its strengths and weaknesses, existing frameworks are born to help us part of the organization of the system, not least us. anything you need to drag the Framework in and then you have to cram the many messy rules that each Framework requires
- Testable: The design of business rules can be tested without using UI, Database, Web-Server or other external factors.
- Independent of UI (Independent of UI or any other interface): Changing the interface will happen very often but this does not affect changing the business rules.
- Independent of Database: whether your application can change from MySql to Mongo or PostgreSQL, business rules will not be affected.
- Independent of any external agency: No matter how the outside world changes, something like other libraries will change, it will not affect business rules.
The Clean Architecture is divided into 4 layers with a 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.
The complexity of the layers also increases from the inside out. The more inside it is, the smaller the complexity (The complexity here is only the amount of framework, library used => The more inner layer is, the less use)
As shown below, we can see 4 layers of Clean Architecture:
- Entities
- Use cases
- Interface Adapters
- Frameworks & Drivers
1. Entities
Entity will contain business rules. An Entity can be an object with basic methods or the structure of this object and as long as it can be used by many different applications throughout the software.
For example: With the problem of building a To do application that allows creating tasks Then the entity here will be the Task.
2. Use cases
Application Business Rules: These are the use case of the system. Requirements (eg requirement of a function). With outsourcing projects, it is usually the customer that sets the business rule, while with product products, it is usually the person who is in charge of the product, the owner of the product.
- Use cases use internal entities to solve the problem.
- Use case has nothing to do with UI or database
- This is an important layer, when making large applications, it is possible to share this layer with other applications. For example, building an application on many different types of devices, be it on smartphones and smartwatches. The display may be different but basically the function and use case of the program are almost the same => can be shared and used
- If you talk about changes, Use cases is the least changed layer (that is, the code is least modified).
3. Interface Adapters
An equally important component in our software system is Interface Adapters. This is a set of adapters that transfer data from one layer to another. For example, the adapter converts data from use cases and Entities / Domain Models into data for Database (Database Model) and vice versa (Data Mapper).
Do not confuse this Adapters layer with Apdater Reyclerview or ListView. It is possible that the Adapter in recyclerview / list view may be part of the Adapter but otherwise not
4. Frameworks & Drivers
This outer layer contains code related to the framework, DB, UI, etc. which are not related to the main logic of the system.
These are some of the elements that can be in the outermost circles, generally you don’t write a lot of code in this layer except the code to connect to the inner circles. This layer is where the focus of details. We will keep these outside, where they can hardly affect the inner circle.
5. So why use Clean Architecture?
Benefits of using Clean Architecture:
- Completely separate layers from each other with separate tasks to make editing easier.
- Increase abstraction
- Avoid binding
- Easy to test
Following these simple rules is not a difficult task but it will save us a lot of time in the future. By splitting the system into layers and following the Dependency Rule, we will build an easy-to-test system, along with the benefits mentioned above. When any external parts of the system become obsolete, such as databases, or web frameworks, you can completely replace them with a minimum of effort.
6. Restrictions
Color is also a must not mention the limitations of Clean Architecture.
- One thing that everyone realizes is that the implementation of Clean Architecture is quite complex and cumbersome
- The level of team when applying Clean Architecture is also interesting because it requires quite a lot of knowledge.
Deploying layers is time consuming and complicated. So do we always need to fully deploy 4 layers? In my opinion, the answer is no, depending on the system, there will be a number of different classes, not necessarily separate entities and use cases.
End P1
The content of the article is relatively long and there are many so I would like to save for P2 and stop here. 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. Thank you for reading.