flutter-architecture

Topics in the source

• Flutter architecture
• 1. The layers
• 2. Scale the structure to the project
• 3. Data, networking, persistence
• 4. App-level decisions
• 5. Day-one setup checklist (do these before feature work)
• 6. Scaling teams and legacy (LeanCode + VGV experience)
• Sources

Verified 2026-09-25 against docs.flutter.dev/app-architecture (Flutter 3.47), engineering.verygood.ventures, and pub.dev. For Dart syntax and widget code style, see the flutter-dart-style skill. For state libraries, see flutter-state-management. Core rule (Flutter team, "strongly recommend"): separate the UI layer from the data layer, keep widgets dumb, and let data flow one way. Everything else is scaled to the project's size. Service: wraps exactly one external source (REST client, DB, platform plugin, SharedPreferences). No business logic. Returns raw/API models. Repository: the source of truth for one kind of data (UserRepository, BookingRepository). It combines services, caches, retries, maps API models to domain models, and exposes Future > or Stream . No Flutter imports. Define it as an abstract class (officially "strongly recommend"), so tests use fakes and dev/staging use other implementations. ViewModel / Cubit / Notifier: one per screen or feature. Turns repository data into UI state and exposes actions (Commands/methods). No BuildContext, no widgets. View: layout, simple ifs, animation, routing. No business logic. Domain layer / use-cases: conditional. Add them only whe

This is an excerpt. Refer to the complete source and its current requirements.