🔧 Flutter Clean Architecture - Fast Feature-First Setup Guide

📘 Note: This is a fast and simple setup guide for structuring Flutter projects using Clean Architecture with a feature-first approach. It is consolidated from multiple references and shaped by practical experience in real projects. Intended for quick implementation. This is how i structure and work on projects.

🧪 Step-by-Step Plan

1. Analyze the Figma Design

• Review the Figma design thoroughly.
• Identify all distinct features based on the UI/UX.
• Each feature should be represented as a folder inside the features/ directory.

2. Define API Properties per Feature

• For each feature, identify the API endpoints it depends on.
• Extract only the necessary properties from each API response (avoid using the entire response).

3. Create the features/ Folder

• Add a subfolder for each feature inside features/.
• Each feature will contain its own:
  • data/
  • domain/
  • presentation/

4. Create Data Models (DTOs)

• Define models inside features/<feature>/data/models/.
• Deserialize only the fields needed from the API.
• Add a toEntity() method to convert the model to its corresponding entity.

5. Define the Entity Object

• Place entity classes inside features/<feature>/domain/entities/.

• These classes:

  • Contain business logic
  • Do not contain fromJson / toJson

• Add validation and domain-level calculations here.

6. Create the Data Source Layer

• Inside features/<feature>/data/datasources/:
  • Define an abstract class (e.g., UserRemoteDataSource)
  • Implement a concrete class (e.g., UserRemoteDataSourceImpl) using http
• This layer returns models, not entities.
• Optionally, support local data sources (Hive, SharedPreferences, etc.).

7. Create the Repository Layer

• Define an abstract repository in features/<feature>/domain/repositories/.
  • Return entities, not models.
• Implement the repository in data/repositories/:
  • Use the data source abstract class, not concrete one [0].
  • Optionally use multiple data sources.
  • Use try/catch for error handling.
  • Return results using the Result pattern [2].

8. Create the Use Cases Layer

• Inside features/<feature>/domain/usecases/, define use case classes.
• Each use case:
  • Performs one responsibility
  • Depends on the repository abstract class
  • Returns either entities or Result

9. Create the Presentation Layer

• Inside features/<feature>/presentation/:
  • Add ui/ (screens, widgets)
  • Add controllers/ (ViewModels, BLoC, etc.)
• Separate screens and controllers for each UI if needed.
• Use internationalization for all labels and strings.

10. Create Shared and Core Folders

• Outside features/, create:
  • shared/: Shared features.
  • core/: constants, error handling, API clients, utilities
• These folders hold reusable components for the entire app.

🔁 Example Folder Structure

lib/ ├── core/ │ └── (helpers, utils, constants, etc.) ├── shared/ │ └── (shared features) ├── features/ │ ├── <feature_name>/ │ │ ├── data/ │ │ │ ├── models/ │ │ │ ├── datasources/ │ │ │ └── repositories/ │ │ ├── domain/ │ │ │ ├── entities/ │ │ │ ├── repositories/ │ │ │ └── usecases/ │ │ └── presentation/ │ │ ├── ui/ │ │ └── controllers/ 

📚 References

• [0] https://techdynasty.medium.com/solid-principles-in-flutter-b868fb5ef60e
• [1] https://codewithandrea.com/articles/flutter-project-structure/
• [2] https://docs.flutter.dev/app-architecture/design-patterns/result#putting-it-all-together
• https://medium.com/@yamen.abd98/clean-architecture-in-flutter-mvvm-bloc-dio-79b1615530e1