Clean Architecture
Introduction to Clean Architecture
Clean Architecture, introduced by Robert C. Martin (Uncle Bob), is a software design paradigm that promotes the separation of concerns by organizing the system into distinct layers. Each layer in Clean Architecture serves a specific role and adheres to certain principles to ensure that systems are flexible, testable, and maintainable. One of the key goals of Clean Architecture is to make the core business logic (domain) independent of frameworks, databases, or UI, ensuring that changes in external systems don’t affect the core business logic.
Clean Architecture is typically divided into the following four layers: Domain, Application, Infrastructure, and Presentation. These layers are organized in a way that follows a "dependency rule," which ensures that inner layers do not depend on outer layers, but outer layers depend on inner ones.
1. Domain Layer
The domain layer is the core of Clean Architecture. It represents the business rules, logic, and entities that define the fundamental operations of a business. The domain layer is completely independent of any technology or external system, meaning it should not be affected by changes in frameworks, databases, or user interfaces.
In Clean Architecture, the domain layer is often where entities (core business objects) and value objects (immutable objects representing domain-specific concepts) reside. It is focused entirely on the business itself—what the business does, its rules, and constraints.
Characteristics of the Domain Layer:
Independent of any external systems such as databases, UI, or frameworks.
Contains core business logic and rules.
Includes entities and value objects that represent business concepts.
Does not depend on other layers.
Example:
In a movie rental business, the domain layer would define the essential rules for renting movies, calculating fees, determining rental durations, and managing customer interactions with movies. These processes exist regardless of the the technology used to execute them.
2. Application Layer
The application layer deals with use cases—the specific business actions that are performed. It orchestrates the execution of business rules defined in the domain layer by applying them to specific scenarios. While the domain layer defines what should happen in the business, the application layer defines how it happens in specific situations.
The application layer is responsible for coordinating activities across different entities and enforcing business rules in a way that reflects real-world workflows. This layer is crucial in ensuring that all business logic is implemented correctly and can also handle user input by invoking the right domain logic.
Key Aspects of the Application Layer:
Defines use cases that dictate how business logic is applied.
Coordinates activities between different parts of the system (entities, services).
Depends on the domain layer but not on external systems (UI, databases).
Sometimes called the service layer or use case layer.
Example:
For the movie rental system, the application layer would orchestrate the rental process—checking the availability of a movie, verifying customer status, and enforcing late fees. This layer implements the workflow of renting a movie but relies on the domain layer's business rules.
3. Infrastructure Layer
The infrastructure layer is where all external dependencies and technical details are handled. It includes everything related to database management, APIs, messaging systems, file storage, and any other external systems that the application interacts with. The infrastructure layer exists to support the application and domain layers by providing the necessary services (like data persistence) but does not define business logic.
This layer must not impose constraints on the domain or application layers. Instead, it should be designed in a way that it can be swapped or modified without affecting the inner layers. The infrastructure layer serves as the adapter, translating requests from the application layer into database queries, API calls, or system-level actions.
Characteristics of the Infrastructure Layer:
Deals with technical operations such as data storage, external APIs, and system resources.
Provides services like database access and messaging systems.
Depends on the application layer to know how data should be persisted or retrieved.
Should be easily replaceable without affecting core business logic.
Example:
In a movie rental system, the infrastructure layer would manage the actual storing of rental records in a database, integrating with external services for payment processing, or sending notifications. It ensures that the technical aspects of the system are handled, but it doesn't control business decisions.
4. Presentation Layer
The presentation layer is the outermost layer and deals with how the application communicates with its users. It is responsible for the user interface (UI) and handles displaying data to the user and accepting inputs. The presentation layer should not contain any business logic. Instead, it invokes the application layer, which in turn applies the appropriate business rules.
The presentation layer should adapt to different types of interfaces—web, mobile, or desktop—and should only be concerned with delivering the correct user experience, not how the business logic works.
Key Aspects of the Presentation Layer:
User-facing layer that handles UI and user interaction.
Depends on the application layer to retrieve data and execute use cases.
Can include web interfaces, mobile apps, or desktop GUIs.
Should remain independent of the domain and infrastructure.
Example:
For the movie rental system, the presentation layer would display available movies, present rental options to customers, and allow users to interact with their accounts. It sends user actions (e.g., movie selection) to the application layer to be processed, but it doesn't handle business decisions directly.
Dependency Rule in Clean Architecture
A fundamental rule in Clean Architecture is the dependency rule: source code dependencies can only point inward. The outer layers (Presentation and Infrastructure) depend on the inner layers (Application and Domain), but the inner layers are independent of the outer ones. This ensures that the core business logic (Domain Layer) remains unaffected by changes in technology (Presentation and Infrastructure layers).
Conclusion
Clean Architecture divides the system into distinct, well-defined layers, each with specific responsibilities. This separation allows for greater flexibility, maintainability, and testability by isolating business logic from external dependencies and ensuring that changes in one layer do not ripple unnecessarily into other parts of the system.
The Domain Layer is the core, holding the business rules and logic.
The Application Layer defines the use cases and workflows.
The Infrastructure Layer manages the technical details such as databases and APIs.
The Presentation Layer handles user interaction and display.
By adhering to these principles, Clean Architecture ensures that software systems remain adaptable and resilient to changes in technology and business requirements.