The clean architecture was developed by Robert Cecil Martin (co-author of the Agile Manifesto) and provides a structure that supports maintainable applications. It has one main objective, the separation of concerns. Other, often similar concepts have been introduced that promote maintainable applications, and they all have in common that they address the separation of concerns. We choose to explain the clean architecture in this design guide, as it is a good example of an architecture that addresses the separation of concerns.

In the clean architecture, the separation of concerns is achieved by the following rules:

• Split software into at least the following layers (Domain Layer, Application Layer and Interface Layer)
• Prevent mixing of layers by using decoupling. This is needed within each layer but also when boundaries between layers are crossed.

This will result in a system with the following characteristics:

• It is intrinsically testable, with all benefits attached to that. 
• Independent of UI. The UI can change easily, without changing the rest of the system.
• Independent of Database. You can swap out one database for another, and your business rules do not know the difference.
• Independent of any external system. The business rules should not have to change when external systems change. Please note that business rules may change if these reflect law or regulations.
  

Below is the original figure from the clean architecture:

An important rule in the clean architecture is the dependency rule. It states that all dependencies should point inwards. For example are the use cased allowed to know elements from the domain, but not the other way around. This is also called decoupling.

In the remainder of this design guide we use the figure shown below, which is in essence similar as above. It is lovingly called the onion ring.

While these layers address different concerns (displaying information to the user in the outer layer vs. business rules in the inner layer.), we can also distinguish a separation of concern within a single layer. The best example is found in the domain layer, in which business rules are placed. Not all rules concern the same topic, and you want them to be decoupled from other rules. This might be an additional layer. You are not limited in the number of ayers layers in the clean architecture. You might also develop the rules separately and create communication between the two using an API. Essentially this means that two onions rings are created that together form a working system. This may be represented by one large onion ring that includes the two smaller onions.

For a detailed explanation of each layer, go to

• Domain Layer
• Adapter Layer
  
• Application Layer
  
• Interface Layer

When you are done, also have a look at Business Rules and the Clean Architecture.