Flutter Clean Architecture

Easier Maintenance and Expansion of Flutter Code with Clean Architecture

Implementing Clean Architecture in Flutter

Common Issues in App Development

When developing software, especially large-scale projects, you may encounter the following challenges:

• Difficulty in maintenance: As the application grows with more features, debugging and fixing issues can become time-consuming.

• Adding new features: Implementing new features may affect the application's flow. A proper approach is needed to ensure that adding new functionalities does not significantly impact existing code.

• Scaling the project: Large projects with limited resources require well-structured code to allow a single developer to manage multiple parts of the application.

• Easier collaboration: Clear and well-structured code makes it easier for team members to hand over or collaborate effectively.

Why Use Clean Architecture for Flutter?

Key Benefits – Solving the Issues Above

Clean Architecture provides an effective solution for organizing code in a structured manner, offering several key advantages:

• Increased flexibility: The most frequently changing components are placed in the outermost layer, making it easier to modify, add new APIs, or access data during maintenance. Features are isolated, allowing team members to develop their parts independently without interfering with others' work.

• Efficient module management: Each module is designed separately, making it easy to maintain and expand. Features are placed in distinct directories to ensure they do not affect each other.

Architecture Structure and My Implementation

• Domain (Core Logic): The innermost layer containing essential business logic, which remains relatively stable.

• Presentation (UI Layer): The middle layer responsible for processing data from the domain and displaying it on the UI.

• Data (Repository & API Layer): The outermost layer, handling API requests and data storage.

Core Principles:

• Inner layers must not depend on outer layers: The domain layer should not directly fetch data from the presentation or data layers.

• Outer layers can access inner layers when needed: The data layer can call domain or presentation layers as required.

Implementing Clean Architecture in Flutter

Implementing Clean Architecture in Flutter

Folder Structure

A Flutter project is typically organized as follows:

lib/
  ├── features/          # Contains main modules  
  │     ├── module_1/    # Each module follows three layers: Data, Domain, Presentation  
  │     └── module_2/  
  ├── ...  
  └── main.dart          # Application entry point  

Detailed Layer Breakdown

Detailed Layer Breakdown

Domain Layer

This is the core layer containing business logic and is rarely modified. It typically includes:

• Entities: Core business objects. I have templates for these entities, you can refer here for using the json_serializable plugin or refer here for the freezed plugin.
• Use Cases: Business logic handlers. Some developers omit this folder, considering it unnecessary. However, I find it essential as it clearly defines the use cases for accessing the data layer. It becomes especially useful when combined with system diagrams.

• Enums: Enumeration values. I frequently use enums in my projects due to their convenience. You can check out my Mason template for enums at dr_enum.

Presentation Layer

This layer handles UI rendering and user interactions. It typically includes:

• Views: Main screens and subcomponents.

• View Models: Manages screen states (state management) using libraries like GetX, BLoC, and Riverpod.
• Widgets: Reusable widgets. If you want to create widgets for reuse across multiple projects, consider packaging them. I will cover this in detail in a future article on Flutter packages.

Data Layer

This is the most volatile layer, containing repositories for data access. It includes:

• Constants: Module-specific constants.

• Repositories: Handles data retrieval from APIs or local storage. In the past, I worked with IoT devices using Bluetooth for data exchange, and that logic also belongs to this layer.

Automated Structure Generation

Manually creating folders and files can be time-consuming, especially when setting up new modules. You can use Mason to automate this process:

• Mason allows you to quickly generate a Clean Architecture structure.

• Reference guide: Boost your Flutter development efficiency with Mason.
• Check out the template: dr_clean_arch on Brickhub.

Implementing Clean Architecture in a Project

Example: PAYMENT Module

Implementing Clean Architecture in a Project

PAYMENT Module Structure

lib/features/payment/
  ├── data/
  │     ├── repositories/    # Repository handling API data
  │     └── constants/       # Payment-related constants
  ├── domain/
  │     ├── entities/        # Entities for processing data
  │     ├── usecases/        # Core use cases (fetching bills, making payments)
  │     └── enums/           # Enums for payment status
  └── presentation/
        ├── views/           # UI screens
        ├── view_models/     # State management using BLoC/GetX
        └── widgets/         # Reusable widgets

Component Details

Domain:

• Entities: Objects representing invoices, customers.

• Use Cases: Functions like payment authentication, retrieving invoice lists.

• Enums: Payment statuses (pending, successful, failed).

Domain

Presentation:

• Views: Displays payment interface and modularized sub-screens for better maintainability.

• View Models: Uses BLoC for state management.

• Widgets: Reusable buttons and payment-related forms.

Presentation

Data:

• Repositories: Handles API calls for payments or offline data storage.

• Constants: Stores API endpoint configurations.

Data

References

Here are some useful references I used:

• Learn more about Clean Architecture
• Flutter Clean Architecture Usage
• Clean Architecture with BLoC

Buy Me a Coffee | Support Me on Ko-fi