The closer you get to the yellow circle, the higher level the code becomes. Uncle Bob describes the inner circles as mechanisms and the outer circles as policies.
The general rule that makes the Clean Architecture work is The Dependency Rule. According to this rule, source code dependencies can only point inwards.
Elements located in the Entities circle (the enterprise business rules) should not refer to any elements outside of it (such as application business rules, interface adapters, frameworks, and drivers).
Data formats used in an outer circle should never be used by an inner circle, especially if they are generated by a framework in an outer circle. The Clean Architecture prevents anything in an outer circle to impact the inner circles.
Here’s a Breakdown of the Diagram
Entities – enterprise-wide business rules that reflect the highest level of business logic.
Use Cases – application-specific business rules, that’s the point where we focus on developing the functionalities of the application that support the rules contained in Entities.
Interface Adapters – a set of adapters that convert data from the format most convenient for the Use Cases and Entities to the format most convenient for an external agency such as a database.
Frameworks and Drivers – a combination of various frameworks and tools such as the database, web frameworks, etc. In general, that layer puts together code that communicates to the next circle inwards.
Naturally, these 4 circles are just schematic. The number of layers depends on many factors, (for example, the application type).
These layers need to communicate with each other. Look at lower right corner hand corner of the diagram – it describes how the communication between these different layers should look like.
How to Cross Circle Boundaries?
The flow of control begins with the Controller and then moves through the Use Case only to end up executing in the Presenter. Each source code dependency points inwards, toward the Use Cases.
When coding in a language like Java, developers aim to arrange interfaces and inheritance relationships in a way that the source code dependencies are in opposition to the flow of control, at the right points of the boundary.
But don’t forget about the Dependency Rule (no name in an outer circle can be used in an inner circle) – that’s why we see the Use Case call an interface and have the Presenter located in the outer circle implement it.
When passing data through these boundaries, developers should take extra care to make sure that the data structures are simple and isolated. They can’t have any dependency that violates the Dependency Rule.
Why Implement the Clean Architecture?
Separating software into layers and following the Dependency Rule is in the interest of every developer who wants to create a robust, testable system that doesn’t depend on external parts like frameworks and databases. When these become outdated, you can just replace them and have your system running in no time.
Getting familiar with these principles can help you avoid falling into the trap of blindly choosing the framework that breaks the Dependency Rule by design.
Want to learn more about the Clean Architecture and other smart programming strategies? Get in touch with us at email@example.com, we’re always happy to share our knowledge.