Clean Architecture

What is Clean Architecture?

Clean Architecture is a very famous application architecture based on the principle of eliminating dependencies between objects as well as layers in the application. This principle inherits and develops based on Dependency Inversion - the famous principle in SOLID.

In Clean Architecture, there are 4 layers represented through concentric circles. The inner circles will not know anything about the outer circles. This "centripetal" principle is illustrated as follows:

Inside and out Clean Architecture will include: Entities, Use Cases, Interface Adapters and Frameworks & Drivers.

Basically, these layers will work through each other's abstractions (interfaces).

Entities

Entities are the innermost layer, also the most important layer. Entities are specific entities or objects and their business logic rules. In OOP, this is the Object with methods and properties that adhere to the principle of Encapsulation - only within the Object can its state change.

For example: In the Person object, the age property cannot be less than 1. If we need to change the age, we must write a public setAge function, which is also responsible for checking the condition related to age.

The business logic of the Entities layer will not care or depend on the business logic in the outer layers like Use Cases. Assuming that the user must be 18 years or older to be allowed to create an account, the Age property rule in Entities remains unchanged.

Use Cases

Use Cases is a layer that contains business logic at the specific level of each Use Case (or application).

For example: Use Case to register an account (create a new Person/Account) will need to combine one or more Entities depending on the complexity of the Use Case.

The business logic of the Use Case, of course, will not care and depend on where the data comes from, what libraries are used as adapters, how the data is represented, ... Because that is the task of the Interface layer Adapters.

Interface Adapters

Interface Adapters is the layer in charge of converting data formats to suit each Use Case and Entities. These data formats can be used both inside and outside the application.

For example: User information will have some very sensitive information such as Email, Phone, Address. The data is not always available enough to serve the GUI (Web, App). Similarly, depending on the Database system, the adapter must format the data properly.

Thus, the input and output data at the Interface Adapter layer only needs to be sufficient and reasonable. It will not care how specifically the data will be displayed or collected. Because that's the task of the Frameworks & Drivers layer.

Frameworks & Drivers

Frameworkd & Drivers is the outermost layer, a combination of specific tools to serve each end user's needs such as: devices, web, application, databases,... In Clean Architecture, it is on this layer. is the "lightest" because we don't need to write too much code.

In fact, this is the place to "know all" specifically what tiers are through being responsible for initializing objects for the inner tiers (aka Setup Dependencies).

Pros and cons of Clean Architecture

Advantages of Clean Architecture

• Divide and conquer is very effective in large applications: In Clean Architecture, each layer of code is in the right layer. Limiting the "code everywhere is code, it can be run". If you can do the small problems well, there is no big problem that can't be solved.

• Very easy to maintain and extend: Finding bugs and logic errors will become easier and faster, the code file will not be much because it just does its job. Since layers are independent of each other through Interfaces, extending or changing layers will not affect each other. This limits breaking changes as well as having to rewrite the code (refactoring).

• Very easy to do Unit Test: The business logic of the layers in Clean Architecture are Unit Tests that need to be tested very carefully. Because of the independence through Interfaces, mock tests are easy to implement. This is done through reimplementation to cover all cases.

Disadvantages of Clean Architecture

• Bulky and complicated: The most obvious thing is that Clean Architecture is not easy to use, having to write more classes (classes / objects). In case your application is too simple, few features, short life cycle then choosing this architecture can bring unnecessary troubles.

• High abstraction: This problem is called indirect. The higher the abstraction, the more convenient it is for developers, but it will greatly affect the performance. In addition, it is not possible to code quickly, rushing "instant noodles" but must create enough Interfaces.

• Difficult to recruit: Using Clean Architecture will require recruiting developers who understand this architecture. The Dependency Inversion principle is easily violated because of limited knowledge, carelessness or because the time it takes to deploy a feature is too short.