An application or a website will usually have 3 main component layers: the interface layer, the business processing layer and the database layer. The three layers of the day will go from the outside to the inside, something that catches your eye like this article is no exception, in order to be visible to readers (client or frontend), it needs to be handled inside or not. They are beautifully called backends, then they are saved somewhere like when you save great videos on your hard drive. You can come across a model representing these 3 layers, which is MVC (Model - View - Controller) or MVP (Model - View - Presenter) or MVVM (Model - View - ViewModel). Regardless of the model, it also divides the responsibility of the three components above.

But there are a few reasons why this 3-layer model gradually turned into a more advanced model.

1. The first is Platform Independent (Independent of Frameworks). What do you do when you save a good movie on this computer's drive but you want to watch them on another computer, either you copy it to a USB like we used to do in the old days or you put them on the cloud. Either way, what you want is flexibility that doesn't depend on equipment or infrastructure. Which technology you use, which language for one of the 3 component classes, no longer matters.

2. The second is easy testing (Testable). Developed software must be tested for bugs before release and clear layer separation makes testing easier. Video in your usb can't be played, either your usb is broken, or your computer is broken, or your screen is broken, whatever it is, you can easily check the components the rest when you bring it through the link with another computer to check easily, it is easier to localize the error that arises.

3. The third is independent of the interface (Independent of UI), fortunately since the advent of computers, we have not been exposed to the first generations of black screens and dry command lines, instead of windows screens with mouse clicks, then gradually it not only lies dead on your computer it can be used anywhere through the web interface, or mobile interface. Dividing the View component separately from the rest helps us have a better user experience and easily adapt to all device conditions.

4. The fourth is not dependent on the database (Independent of Database). As you probably already know, we have many types of databases stored, as well as many types of hard drives or usb or the cloud also has many types such as Google Cloud, iCloud, OneDrive… So how do our applications you don't depend on them, just integrate and they can run smoothly. Separating the database layer helps you do this.

5. Finally not depending on any third party (Indenpendent of any External Agency). Do you think an e-commerce site has many forms of payment. Either form of payment becomes easy and replaceable when you exchange things through API (Application Programming Interface), a protocol for connecting with other libraries and applications.


You can see with this architecture that the concentric circles represent the component layers like an onion. So how does this work?

With Clean Architecture, the 3 main component layers are still preserved but only reorganized from the core to the outside of the shell, including: Entity (Core class working with the database), Usecase (Processing layer). business connection and data exchange with the core layer and interaction with the outer layer), Interface (The shell links and connects to the outside world after processing the business and obtaining data after processing), Driver (Layer that represents or stores data) Then let's peel off each layer from the outside to the inside!


Frameworks and Drivers layer

This is what catches the eye of the user as well as the class that interacts with, communicates with other applications or communicates with databases. The administrative shell is the layer that exposes us to everything, it can be a request from a user of a website, it can be a public api that helps to integrate with a third party or system. external system, maybe a mobile device like Android Apps or Iphone Apps, maybe an analytics tool that reads some database data.

Interface Adapters layer

As the name implies, this is the data conversion layer, when receiving a certain signal from the outer shell, this layer is responsible for converting those requests into the inner processing layer. Think of it as a general-purpose socket, it takes inputs, categorizes them and sends them to the right places, to the right places, to the right handlers, this coordination makes the system easy to integrate with multiple devices. where than that the shell supports. If the outer shell has many platforms such as desktop apps, web apps, mobile apps, 3rd party systems... then after passing this layer, it will be standardized to a single input to your system. can handle them more easily. Inputs at this point can be GraphQL, Restful, Soap, Scheduled Jobs, GUI, Odata… (a bit technical but you can simply understand it as different data transfer protocols) they will be processed into a data stream that the inner core layer can understand and process. .

Use Case layer or Application Logic layer

After the input has been standardized and the data processing areas have been classified, then in this subcore layer, specific transactions will be handled here, maybe it's banking, maybe it's banking. e-commerce business, or simply count the number of upvotes for this article. The business processing at this layer makes it easier for you to categorize your business processing without depending on any external factors as well as unexpected errors from the raw database. It is also easier to test business functions at this layer, modular organization or microservices are also divided according to the business of this layer.

Entities layer

Finally, there is the core domain entity class, with this layer merely mapping data or simply for the purpose of containing raw data, regardless of any libraries, platforms, techniques, or any profession. Raw is raw, it ensures the most original data so that the upper sub-core layer can have business processing data correctly. For green buildings, this layer is the construction materials that have not been processed in any stage of a project such as brick, stone, cement, steel, etc. It only shows the which data are related to each other, data grouping, parent-child relationships as well as their data types.

If you are in the industry and have a bit of background, the picture below will help you identify the technologies in each layer. In this article, I will not explain each technology in this picture, but want to describe in an overview the Clean Architecture architecture.


So, if there are so many advantages, does this architecture have any disadvantages?


The first is that it's complicated, it's because of the abstraction so much, that everything doesn't depend on each other that it doesn't follow any rules. It is this that makes it difficult for programmers to grasp and follow a pre-existing standard like classical architectures.

Next is there is no specific direction, everything is indirect. Because we want to diversify the component classes, they work with each other indirectly, and if we don't check the input and output of each component class, we accidentally make them big holes.

Finally, it is heavy, chopping onions in too many layers will easily make us teary-eyed, when a small application that does not have the need to expand but follows this architecture will make us more difficult because we have to build a lot. many new component classes can make up a simple feature. The question in this case is whether it is really necessary.