Maintain and Extend Code Easily with Clean Architecture for Flutter

Nguyễn Minh Đức — Fri, 07 Feb 2025 01:56:57 +0000

Maintain and Extend Code Easily with Clean Architecture

1. Common Issues in Application Development

When developing software, especially large-scale projects, you may face the following issues:

Maintenance difficulties: Fixing bugs and maintaining functionality can become time-consuming as the application grows.
Adding new features: Clients may request additional features that need to be integrated without impacting existing functionality.
Scaling the project: Large projects with limited resources require a well-organized code structure for efficient development.
Improved collaboration: A clear and structured codebase makes it easier for team members to collaborate and transition responsibilities.

2. Clean Architecture

Key Benefits

Clean Architecture provides a systematic way to organize code, offering benefits such as:

Increased flexibility: The most changeable components are placed at the outer layer, simplifying API updates or data handling during maintenance.
Efficient module management: Each module is designed to be independent, making it easier to maintain and extend.

Architecture Structure

Domain (Core): The innermost layer containing the business logic, which changes infrequently.
Presentation (UI): The middle layer responsible for handling data from the domain and rendering it to the user interface.
Data: The outermost layer responsible for API communication or data storage.

Main principles:

Inner layers must not depend on outer layers: Domain should not directly access Presentation or Data layers.
Outer layers can interact with inner layers: Data can call Domain or Presentation as needed.

3. Implementing Clean Architecture in Flutter

3.1. Folder Structure

A Flutter project is typically organized as follows:

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

3.2. Automating Structure Creation

Manually creating folders and files can be time-consuming, especially when setting up a new module. You can use Mason for automation:

Mason helps generate Clean Architecture structures quickly.
Refer to the tool: Boost your Flutter development efficiency with Mason.
Check out the template: dr_clean_arch on Brickhub.

3.3. Layer Details

Domain Layer

This is the innermost layer, containing the business logic. It usually consists of:

Entities: Core objects that represent data models. Examples include plugins like dr_entity using json_serializable and dr_freezed.
Use Cases: Business logic functions. These highlight how data flows in and out of the data layer, making diagrams or workflows easier to manage.
Enums: Enums simplify state management. Check out templates like dr_enum.

Presentation Layer

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

Views: Screens and their components.
View Models: State management solutions using GetX, BLoC, or Riverpod.
Widgets: Reusable UI components. For reusable widgets across projects, consider placing them in packages.

Data Layer

This layer handles APIs or data storage. It includes:

Constants: Module-specific constants.
Repositories: Manage API calls and local data handling.

4. Implementing Clean Architecture for the PAYMENT Module

PAYMENT Module Structure

lib/features/payment/
  ├── data/
  │     ├── repositories/    # Repository for API handling
  │     └── constants/       # Constants related to payments
  ├── domain/
  │     ├── entities/        # Entities for data processing
  │     ├── usecases/        # Core use cases (fetch bill, process payments)
  │     └── enums/           # Enums for payment status
  └── presentation/
        ├── views/           # UI screens
        ├── view_models/     # State management with BLoC/GetX
        └── widgets/         # Reusable UI components

Component Details

Domain:
- Entities: Represent invoice and customer objects.
- Use Cases: Functionalities like payment validation and fetching invoice lists.
- Enums: Payment states (pending, success, failure).
Presentation:
- Views: Display payment UI.
- View Models: State management with BLoC.
- Widgets: Payment-related buttons and forms.
Data:
- Repositories: Handle payment APIs or offline data.
- Constants: API endpoint configurations.

5. References

If you found this guide helpful, consider supporting my work by buying me a coffee! ☕

DEV Community: Nguyễn Minh Đức