Clean Architecture 🧹
Clean architecture is a software design pattern that separates the elements of a system into layers to better manage complexity. It was proposed by Robert C. Martin (Uncle Bob) and focuses on the following principles:
Layers
Clean architecture divides the software into layers where each layer depends only on the layer below it:
-
Entities (Enterprise Business Rules) - Contains enterprise business objects and rules. Doesn’t depend on anything.
-
Use Cases (Application Business Rules) - Contains application specific business rules. Depends on entities.
-
Interface Adapters (Gateways) - Converts data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or Web. Depends on use cases and entities.
-
Frameworks and Drivers - Contains the details how the application interacts with external systems like the database or web. Depends on interface adapters.
Dependency Rule
The dependency of each layer is strictly unidirectional. Inner layers do not depend on outer layers.
Boundaries
Each layer has a distinct boundary which is enforced by coding against interfaces. Layers communicate with each other through these interfaces.
Benefits
- Improved separation of concerns
- Increased testability
- Reduced coupling between layers
- Easier to modify layer independently
Project structure
- OrderController.java (Entrypoint)
- OrderUseCase.java
- Order.java
- OrderService.java
- OrderRepository.java (Interface)
- OrderRepositoryImpl.java
- UserRepositoryImpl.java
You can see the structure is very similar to DDD except it doesn’t focus as much on domain. The reason being CA focuses on the architecture of the application, whereas DDD focuses on the domain of the application.
Conclusion
The main goal of clean architecture is to create software with decoupled components that can be more easily understood, maintained and tested.