It's an architectural style that aims to separate software modules into different layers based on a set of principles. This approach was introduced by Robert Martin and is widely used to develop scalable, maintainable and testable code systems.
It's closely related to other similar architectures, such as Hexagonal, Onion and DDD architectures, which all share the same objective of keeping the application domain and business logic at the centre of the architecture.
It's closely related to similar architectures known as Hexagonal, Onion and DDD architectures. They all share the same purpose: to keep the application domain and business logic at the centre of the architecture.
The clean architecture is divided into four layers:
Entities: Known as Enterprise Business Rules, these are core business entities of the application. They represent plain entities with no layer dependencies.
Use Cases: This layer defines the Application's Business Logic. "These use cases orchestrate the flow of data to and from the entities and direct those entities to use their enterprise-wide business rules to achieve the goals of the use case." Clean Coder Blog
Interface Adapters: These are the bridge between the use cases and external dependencies such as Databases, APIs or User Interfaces (UIs). Their role is to transform the data from the Use cases layer to external systems and vice versa. This layer contains Controllers, APIs and Interfaces.
Frameworks and Drivers: It's the layer responsible for communicating with external environments like Web Frameworks, UIs, Devices and Databases. It handles all the low-level detail implementations from external sources.
The main objective of the Clean Architecture style is to ensure that dependencies go from outer layers to inner ones. External dependencies rely on adapters to establish indirect communication with the business logic. Although, the latter doesn't know anything about frameworks and drivers. Uses cases employ domain entities to route data using adapters. The innermost layer, Entities, has no dependencies on any other layer.
The Stable Dependencies Principle states: "All the dependencies should be directed from less stable modules that change often to more stable modules that change less often." Clean Architecture—Everything You Need to Know (codilime.com)
Entities and Use cases are the most stable inner layers that rarely change, while Frameworks and Drivers are specific implementations that are often modified.
NOTES
Based on the quote posted by Robert Martin: "The architecture should scream the intent of the system!". Don't force the system to adapt to a specific architectural style all the time because it depends on your application and its requirements.
"Architecture doesn't enforce structure. There is no silver bullet or universal framework that can fit any app." “Clean” Architecture vs pragmatic architecture (mews.com)
It´s better to start with a simple and flexible structure. Don't try to add "regarding" code thinking in future implementations. Applying the YAGNI Principle: "Features should only be added when required."
BENEFITS
It's based on Design principles, Separation of concerns and the creation of Flexible, Maintainable and Testable systems.
It follows SOLID Principles, Domain-Driven Design (DDD), Design Patterns and Microservices Architecture.
UI, Database, Framework and External Agencies are Independent from the Core Business Logic. So, it allows switching or modifying outside worlds without affecting the Core inner layers, which remain the same.
Highly testable business logic and domain by isolating both inner layers from outer ones.
DRAWBACKS
Difficult to implement in smaller, fixed resource projects where simpler or pragmatic architectures are more appropriate.
The initial steep learning curve as the architecture itself involves several design principles to control and apply in the correct way.
Using additional layers adds complexity, and clean architecture is more beneficial for large systems where maintainability and flexibility are a must.
Check out my video:
Comments