flutter-project-structure

Organize code into lib/app (composition root), lib/core (infrastructure), lib/shared (generic widgets), and lib/features where each feature contains data, domain, and presentation subfolders. Name features by capability like auth or tasks, not by screen.

Layer-first uses global folders like lib/screens and lib/models, scattering one feature across many directories. Feature-first places the MVVM layers inside each feature folder, so all code for one capability lives in a single place and scales past five features.

Promote a widget to lib/shared only when two or more unrelated features use it and it is stateless or parameter-driven. Widgets that read feature providers or hold business logic must stay inside their owning feature.

Yes, the layout is state-agnostic. The folder tree, layer boundaries, and dependency rules are identical for both; only the state holder files inside presentation change shape between Bloc/Cubit classes and Riverpod providers.

Use melos or Dart pub workspaces only when two or more apps share code, internal packages evolve alongside consumers, or five or more developers need independent package boundaries. A single app should stay single-package.

Enforce boundaries with lints such as custom_lint or very_good_analysis so cross-layer imports fail flutter analyze. Domain must never import Flutter or data implementations, and features must never import each other directly.