Flutter Clean Architecture: Introduction & Project Setup

October 27, 2024

Clean architecture, proposed by Robert C. Martin (Uncle Bob), offers a way to build scalable, easy to debug, adaptable software. We separate different parts of code with specific functionality to create well organized and easy-to-maintain codebase. Imagine independent sections working together. The key here is how these sections rely on each other – dependencies flow inwards, which ensures the core functionalities remain independent even if any external factor changes. This makes the codebase adaptable and ready for future modifications. Flutter Clean Architecture uses separation of concern in a Feature based design to further organize the codebase.

Layers of Clean Architecture

Typically Clean Architecture is divided into 3 layers:

Presentation Layer

The Presentation Layer is responsible for handling the UI and user interactions. In a Flutter application, this layer consists of Screen, State Management, Widget . The main components include:

Screen: different Screens for this specific feature feature
Widget: different Reusable Widgets for this specific feature
State Management: State Management logic which also acts as mediator between UI layer and Domain layer for processing inputs and updating UI accordingly

Domain Layer

The Data Layer is responsible for data retrieval and storage. It interacts with external source (API and database) and internal storage. The primary components are:

Repository: Implemented form of of repository for specific feature
Source: Remote and Local data source for specific feature
DTO: Data Transfer Object for specific feature

Data Layer

The Data Layer is responsible for data retrieval and storage. It interacts with external source (API and database) and internal storage. The primary components are:

Repository: Implemented form of of repository for specific feature
Source: Remote and Local data source for specific feature
DTO: Data Transfer Object for specific feature

Setting up Flutter Project for Clean Architecture

You can find all of the implementations in the following GitHub link: Github Repository

Step 1: Create a New Flutter Project

				
					flutter create flutter_clean_architecture
cd flutter_clean_architecture

Step 2: Organize the Project Structure

				
					lib/
|-- feature/
|   |-- feature1/
|       |-- data/
|       |   |-- dto/
|       |   |   |-- model_dto.dart
|       |   |-- repository/
|       |   |   |-- feature_repository_impl.dart
|       |   |-- source/
|       |   |   |-- feature_local_source.dart
|       |   |   |-- feature_remote_source.dart
|       |-- domain/
|       |   |-- entity/
|       |   |   |-- entity.dart
|       |   |-- repository/
|       |   |   |-- feature_repository.dart
|       |   |-- usecase/
|       |   |   |-- action_1_usecase.dart
|       |   |   |-- action_2_usecase.dart
|       |-- presentation/
|       |   |-- bloc/
|       |   |   |-- bloc1/
|       |   |   |   |--[BLOC_CONTENT]
|       |   |   |-- bloc2/
|       |   |   |   |-- [BLOC_CONTENT]
|       |   |-- cubit/
|       |   |   |-- cubit1/
|       |   |   |   |-- [CUBIT_CONTENT]
|       |   |   |-- cubit2/
|       |   |   |   |-- [CUBIT_CONTENT]
|       |   |-- screen/
|       |   |   |-- screen1/
|       |   |   |   |-- screen1_screen.dart
|       |   |   |-- screen2/
|       |   |   |   |-- screen2_screen.dart
|       |   |-- widget/
|       |   |   |-- specific_widget_folder/
|       |   |   |   |-- widget1.dart
|       |   |   |   |-- widget2.dart
|       |   |   |-- widget3.dart
|-- main.dart

feature: Features are placed in this folder making separate folder for separate feature. We use feature based folders.
- data: This folder has everything related to data layer.
  - dto: DTOs for this feature. A Data Transfer Object (DTO) is a simple object used to transfer data between software application subsystems without any business logic.
  - repository: Implementation of the repositories defined in the domain layer.
  - source: Local and remote source. Local source handles data stored locally and remote source handles data stored in remotely.
- domain:
  - entity: Entities for this feature. Entities are models used in this feature.
  - repository: Contains abstract repository. Repository is An abstract class defining the methods that need to be implemented in the data layer.
  - usecase: Contains the use cases, which are the actions of the application. Actions include delete, add, update etc.
- presentation:
  - bloc / cubit: This folder contains state management logics. We are using bloc as statement tool. Any other state management tool can be used.
  - screen: Defines the UI screens. Contains file for a screen. Each screen has their own folder.
  - widget: Contains reusable UI components.

Step 3: Installing required dependencies & dev_dependencies

After starting new project install following as dependencies:

				
					dependencies:
  bloc: ^8.1.4
  cupertino_icons: ^1.0.6
  dio: ^5.4.3+1
  equatable: ^2.0.5
  flutter:
    sdk: flutter
  flutter_bloc: ^8.1.6
  get_it: ^7.7.0
  injectable: ^2.4.2
  shared_preferences: ^2.2.3

Also add following as your dev_dependencies:

				
					dev_dependencies:
  build_runner: ^2.4.11
  flutter_lints: ^3.0.0
  flutter_test:
    sdk: flutter
  injectable_generator: ^2.6.1

Note: We are using latest version which may change in future.

In upcoming chapter we will deep dive into specific implementation. We will create a sample project and work alongside to get a better understanding of Flutter Clean Architecture.

You can find all of the implementations in the following GitHub link: Github Repository

Read more in upcoming chapters to learn more about all of the layers of Clean Architecture.