Clean Architecture in Flutter: What It Actually Looks Like in a Generated Project
Clean Architecture in FlutterInit means lib/src/features with data, domain, and presentation — not a textbook diagram. Here’s the real tree.
Stack Configuration — what FlutterInit generates for this guide
When to choose this stack
Use Clean when you want repository interfaces in domain, Firebase (or other backends) isolated in data, and UI that only talks to presentation state.
Clean Architecture in a FlutterInit project is concrete: lib/src/features/auth/domain holds entities and repository interfaces; data holds models and implementations; presentation holds Riverpod/Bloc/Provider/MobX and screens. No enterprise PDF required.
The real folder tree
For Clean (and Feature-First), auth looks like:
domain/entities/user.dartdomain/repositories/auth_repository.dartdata/models/user_model.dartdata/repositories/auth_repository_impl.dartpresentation/providers/…(state library of your choice)presentation/screens/login_screen.dart(etc.)
Home and onboarding ship as presentation screens first — expand domain/data when those features grow.
Domain stays backend-agnostic
AuthRepository doesn’t import Firebase or Supabase. The impl and AuthService do. That’s the swap point when you change backends later.
Presentation is where state libraries live
Pick Riverpod, Bloc, Provider, or MobX in the wizard. Files land under presentation/providers with the right pattern (StateNotifier, Bloc, ChangeNotifier, MobX store).
What Clean is not (here)
- Not a separate
usecases/folder in every template (don’t invent one unless you add it) - Not different from Feature-First’s physical paths in current templates — naming and docs carry intent
Full stack walkthrough: Riverpod + Clean + Firebase. Compare packaging: Feature-First vs Clean.
Generate Clean on /create.
Ready to build?
Generate this project in seconds
FlutterInit scaffolds the entire structure described in this guide — wired up, typed, and ready for flutter run.