home / skills / madteacher / mad-agents-skills / flutter-architecture

flutter-architecture skill

/flutter-architecture

This skill guides structuring Flutter apps with MVVM, feature-first organization, and clean layers to improve scalability, maintainability, and team

npx playbooks add skill madteacher/mad-agents-skills --skill flutter-architecture

Review the files below or copy the command above to add this skill to your agents.

Files (9)
SKILL.md
5.1 KB
---
name: flutter-architecture
description: Comprehensive guide for architecting Flutter applications following MVVM pattern and best practices with feature-first project organization. Use when working with Flutter projects to structure code properly, implement clean architecture layers (UI, Data, Domain), apply recommended design patterns, and organize projects using feature-first approach for scalable, maintainable apps.
---

# Flutter Architecture

## Overview

Provides architectural guidance and best practices for building scalable Flutter applications using MVVM pattern, layered architecture, and recommended design patterns from the Flutter team.

## Project Structure: Feature-First vs Layer-First

Choose the right project organization based on your app's complexity and team size.

### Feature-First (Recommended for teams)

Organize code by business features:

```
lib/
├── features/
│   ├── auth/
│   │   ├── data/
│   │   ├── domain/
│   │   └── presentation/
│   ├── todos/
│   │   ├── data/
│   │   ├── domain/
│   │   └── presentation/
│   └── settings/
│       ├── data/
│       ├── domain/
│       └── presentation/
├── shared/
│   ├── core/
│   ├── data/
│   └── ui/
└── main.dart
```

**When to use:**
- Medium to large apps (10+ features)
- Team development (2+ developers)
- Frequently adding/removing features
- Complex business logic

**Benefits:**
- Features are self-contained units
- Easy to add/remove entire features
- Clear feature boundaries
- Reduced merge conflicts
- Teams work independently on features

See [Feature-First Guide](references/feature-first.md) for complete implementation details.

### Layer-First (Traditional)

Organize code by architectural layers:

```
lib/
├── data/
│   ├── repositories/
│   ├── services/
│   └── models/
├── domain/
│   ├── use-cases/
│   └── entities/
├── presentation/
│   ├── views/
│   └── viewmodels/
└── shared/
```

**When to use:**
- Small to medium apps
- Few features (<10)
- Solo developers or small teams
- Simple business logic

**Benefits:**
- Clear separation by layer
- Easy to find components by type
- Less nesting

## Quick Start

Start with these core concepts:

1. **Separation of concerns** - Split app into UI and Data layers
2. **MVVM pattern** - Use Views, ViewModels, Repositories, and Services
3. **Single source of truth** - Repositories hold the authoritative data
4. **Unidirectional data flow** - State flows from data → logic → UI

For detailed concepts, see [Concepts](references/concepts.md).

## Architecture Layers

Flutter apps should be structured in layers:

- **UI Layer**: Views (widgets) and ViewModels (UI logic)
- **Data Layer**: Repositories (SSOT) and Services (data sources)
- **Domain Layer** (optional): Use-cases for complex business logic

See [Layers Guide](references/layers.md) for detailed layer responsibilities and interactions.

## Core Components

### Views
- Compose widgets for UI presentation
- Contain minimal logic (animations, simple conditionals, routing)
- Receive data from ViewModels
- Pass events via ViewModel commands

### ViewModels
- Transform repository data into UI state
- Manage UI state and commands
- Handle business logic for UI interactions
- Expose state as streams or change notifiers

### Repositories
- Single source of truth for data types
- Aggregate data from services
- Handle caching, error handling, retry logic
- Expose data as domain models

### Services
- Wrap external data sources (APIs, databases, platform APIs)
- Stateless data access layer
- One service per data source

## Design Patterns

Common patterns for robust Flutter apps:

- **Command Pattern** - Encapsulate actions with Result handling
- **Result Type** - Type-safe error handling
- **Repository Pattern** - Abstraction over data sources
- **Offline-First** - Optimistic UI updates with sync

See [Design Patterns](references/design-patterns.md) for implementation details.

## When to Use This Skill

Use this skill when:
- Designing or refactoring Flutter app architecture
- Choosing between feature-first and layer-first project structure
- Implementing MVVM pattern in Flutter
- Creating scalable app structure for teams
- Adding new features to existing architecture
- Applying best practices and design patterns

## Resources

### references/
- [concepts.md](references/concepts.md) - Core architectural principles (separation of concerns, SSOT, UDF)
- [feature-first.md](references/feature-first.md) - Feature-first project organization and best practices
- [mvvm.md](references/mvvm.md) - MVVM pattern implementation in Flutter
- [layers.md](references/layers.md) - Detailed layer responsibilities and interactions
- [design-patterns.md](references/design-patterns.md) - Common patterns and implementations

### assets/
- [command.dart](assets/command.dart) - Command pattern template for encapsulating actions
- [result.dart](assets/result.dart) - Result type for safe error handling
- [examples/](assets/examples/) - Code examples showing architecture in practice

Overview

This skill provides a practical, opinionated guide for architecting Flutter applications using the MVVM pattern, layered architecture, and a feature-first project organization. It focuses on scalability, team workflows, and maintainable code structure so you can build apps that are easy to extend and test. Use it to establish consistent boundaries between UI, Domain, and Data layers and to adopt recommended design patterns for robust apps.

How this skill works

The skill inspects your app-level needs (team size, feature count, complexity) and recommends either a feature-first or layer-first layout. It defines responsibilities for Views, ViewModels, Repositories, Services, and optional Domain use-cases, and shows how to expose state, handle errors, and implement unidirectional data flow. It also codifies practical patterns like Command, Result types, Repository abstraction, and offline-first strategies.

When to use it

  • Designing or refactoring a Flutter app architecture
  • Choosing between feature-first and layer-first project organization
  • Implementing MVVM with clear UI→logic separation
  • Scaling an app for multiple developers or teams
  • Adding new features while minimizing merge conflicts
  • Applying tested design patterns for error handling and offline support

Best practices

  • Prefer feature-first organization for medium/large apps and teams to keep features self-contained
  • Keep Views thin: move logic into ViewModels and expose state via streams or change notifiers
  • Make Repositories the single source of truth and aggregate Services for caching and retries
  • Use a Result type and Command pattern to encapsulate actions and errors consistently
  • Adopt unidirectional data flow: data → logic → UI for predictable state management
  • Introduce a Domain layer with use-cases when business logic grows complex

Example use cases

  • New team project with 10+ features: start feature-first to enable parallel work
  • Refactor a monolithic app: migrate modules into feature folders with clear data/domain/presentation boundaries
  • Implement offline-first behavior: repository handles cache, sync, and optimistic UI updates
  • Replace widget-heavy controllers: move UI logic into ViewModels and expose testable state
  • Add third-party APIs: wrap each API in a Service and expose through repositories

FAQ

When should I choose layer-first over feature-first?

Choose layer-first for small apps or solo projects with fewer than ~10 features where simpler navigation by type improves developer speed.

How do I test ViewModels and Repositories?

Unit-test ViewModels by mocking repositories and asserting exposed state changes. Test repositories by mocking Services and verifying caching, error handling, and retry logic.