Mastering Clean Architecture in Flutter

Clean Architecture, introduced by Robert C. Martin (Uncle Bob), has become a cornerstone of modern mobile application development. In Flutter, implementing Clean Architecture helps solve the common problem of mixing UI presentation with network data fetching and business logic. By separating concerns into distinct layers, we create codebase architectures that are scalable, testable, and highly maintainable.

The Three Architectural Layers

Clean Architecture separates code into three primary layers, each with its own specific responsibility:

1. **Domain Layer (Core Business Logic)**: - This is the inner-most layer and must remain completely independent of external packages, databases, and frameworks. - It contains **Entities** (core business models), **Use Cases** (interactors containing application-specific rules), and **Repository Interfaces** (defining contracts for fetching/saving data).

2. **Data Layer (Data Source Management)**: - This layer is responsible for supplying data to the domain layer. - It contains **Models** (data representations that extend entities and add serialization logic like fromJson and toJson), **Repository Implementations** (which execute the domain repository contracts), and **Data Sources** (fetching data from local databases, storage, or external HTTP APIs).

3. **Presentation Layer (UI and State Management)**: - This is the outer-most layer where state controllers, animations, and widgets live. - It handles user interactions, manages state updates (using BLoC, Riverpod, or Cubit), and renders the UI according to business data.

---

Clean Architecture Dependency Rule

The absolute rule of Clean Architecture is that **dependencies can only point inwards**. Outer layers can know about inner layers, but inner layers must never know about outer layers.

  [ Presentation (UI/Controllers) ] ──> [ Domain (Entities/Usecases) ] <── [ Data (Models/Repos) ]

• The **Domain** layer has zero dependency on UI frameworks (like Flutter core) or DB libraries (like SQLite/Hive). It is pure Dart.
• The **Data** layer implements interfaces defined in the **Domain** layer.
• The **Presentation** layer invokes **Use Cases** from the **Domain** layer.

---

Code Example: Define a Use Case in Dart

Here is a practical example of a Use Case in the Domain layer for retrieving user profile data:

import 'package:dartz/dartz.dart';

// Interface defined in Domain Layer abstract class UserRepository { Future<Either<Failure, UserEntity>> getUserProfile(String userId); }

// Usecase defined in Domain Layer class GetUserProfile implements UseCase<UserEntity, Params> { final UserRepository repository;

GetUserProfile(this.repository);

@override Future<Either<Failure, UserEntity>> call(Params params) async { return await repository.getUserProfile(params.userId); } }

class Params extends Equatable { final String userId;

const Params({required this.userId});

@override List<Object> get props => [userId]; }

Summary of Benefits

• **Decoupled code**: If you decide to switch from Firebase to a PostgreSQL database, you only change the Data layer. The Domain and Presentation layers remain completely untouched.
• **Easy mocking**: Because all external boundaries are defined as repository interfaces, you can mock databases and API responses instantly during unit testing.
• **Team scalability**: Developers can work on separate layers simultaneously without blocking each other.