flutter-architecturelisted

# Flutter architecture 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. ## 1. The layers ``` View (widget) ──calls commands/methods──▶ ViewModel | Cubit | Notifier ──▶ Repository ──▶ Service ◀──────────── listens to immutable state ◀───────────── returns models / Result ◀─ raw data ``` - **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<Result<T>>` or `Stream<T>`. 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 `if`s, animation, routing. No business logic. - **Domain layer / use-cases: conditional.**