Flutter Clean Architecture - Feelynx/flutter_clean_architecture GitHub Wiki

This project adheres to the Clean Architecture principles, which ensure a clear separation of concerns by dividing the code into distinct layers: DTOs, Entities, Data Sources, Repositories, Use Cases, and Presentation.

This structure enhances maintainability, testability, and scalability of the codebase.

Overview

Entities

The core business models of the application. These represent the real-world concepts and structures that the system operates on. Entities contain the essential attributes and methods relevant to business logic but are free of external dependencies, making them reusable across different parts of the application.

DTO (Data Transfer Object)

Simple objects used to transfer data between layers, particularly from external sources like APIs or databases to internal entities and vice versa. DTOs often match the data structure of APIs but are not tied to the application's business logic.

Mappers

Handle the transformation between DTOs and Entities. Mappers are responsible for converting external data structures (DTOs) into internal business models (Entities), and vice versa, ensuring consistency and data integrity across layers.

Data Sources

Interface with external systems or databases. They fetch or update raw data, either from local storage (e.g., SQLite) or remote services (e.g., REST APIs), which is then passed through the Mapper layer for conversion into entities.

Repositories

Act as a bridge between data sources and use cases. They aggregate data from multiple data sources (if necessary) and expose a clean API to the application’s domain layer (use cases), abstracting the complexity of raw data operations.

Use Cases

Contain the business logic of the application. Each use case encapsulates a specific operation or workflow, coordinating between repositories and the presentation layer to execute the desired functionality and ensure that the correct data flows to and from the domain.

Presentation

Manages the user interface and application state. This layer handles UI elements, user interactions, and state management using tools like Bloc, Cubit, or other state management solutions. It interacts with use cases to trigger business logic and update the UI based on state changes.

Here's a scheme to make it more clear

Clean Arch Schema