The clean architecture, is an atempt to achieve the separation of concerns. There’s one and only rule, that is the dependency rule. This article is a brief intro about the clean architecture, and it’s principles and sample implementations.
image source: "clean coder - the clean architecture", by Robbert C. Martin
One And Only Rule: The Dependency Rule
The first and only rule is: source code dependencies can only point inwards, not outwards.
In other words, “No name in an outer circle can be mentioned by an inner circle.
Everything else is kinda secondary.
How: The layers
In order to implement the clean architecture, it is required to separate the layers. An application may have at least two to many layers; a layer for business rules, a layer for interfaces.
According to business necessities and technological requirements, you are welcomed to add more layers. There’s no regulations on the number of layers.
Required: Dependency Inversion
In the clean architecture, the conrol flows from the controller to the use case than finally to the presenter.
In the diagram, the controller and the presenter is located outside of the use case.
Wait, isn’t it prohibited to reference names from the outer circle? Yeah you’re probably right.
This flow violates the one and only principle.
That’s why there should be the dependency inversion principle. In Java/Spring world, the Spring container injects dependencies in runtime, on behalf of the developer(which is Inversion of Control, IoC). In Java, perticularly, the use case knows interfaces yet not know actual implementation, the implementation is handled by the outer circles.
The data should be the form taht is most convenient for the inner circle, because the inner circle should not know anything from the outer circle.
- "clean coder - the clean architecture", by Robbert C. Martin