Flutter + Riverpod Clean Architecture

Overview

This skill provides architectural patterns and rules for building Flutter applications using Clean Architecture with Riverpod for state management. Follow these patterns to maintain clear layer boundaries, testability, and scalability.

Architecture Layers

┌─────────────────────────────────────────┐
│           Presentation Layer            │  Flutter UI, Widgets, Routing
├─────────────────────────────────────────┤
│           Application Layer             │  Riverpod Providers, State Management
├─────────────────────────────────────────┤
│              Data Layer                 │  Repositories, External APIs
├─────────────────────────────────────────┤
│             Domain Layer                │  Entities, Value Objects, Business Rules
└─────────────────────────────────────────┘

Layer Dependency Rules

| Layer | Can Depend On | Cannot Depend On | |-------|---------------|------------------| | Domain | Nothing (pure Dart) | Flutter, Riverpod, Firebase, any SDK | | Data | Domain | Flutter, Riverpod, Presentation | | Application | Domain, Data | Flutter UI classes | | Presentation | Application, Domain | Data (direct access) |

Quick Reference

| Layer | Primary Purpose | Key Technology | |-------|-----------------|----------------| | Domain | Business entities, Value Objects | Freezed, pure Dart | | Data | Repository implementations, API calls | Firebase, HTTP clients | | Application | State management, Provider definitions | Riverpod, AsyncNotifier | | Presentation | UI components, routing | ConsumerWidget, go_router |

Layer References

• references/domain-layer.md - Freezed entities, Value Objects, immutable data
• references/data-layer.md - Repository pattern, dependency injection
• references/application-layer.md - Riverpod providers, AsyncNotifier pattern
• references/presentation-layer.md - ConsumerWidget, type-safe routing
• references/ui-patterns.md - Widget composition, anti-patterns

Core Principles

1. Dependency Inversion

• Inner layers don't know about outer layers
• Domain is completely independent
• Data depends only on Domain
• Dependencies flow inward

2. Single Responsibility

• Each layer has a clear purpose
• Repositories handle data access only
• Providers handle state management only
• Widgets handle UI rendering only

3. Testability

• Domain layer is easily unit-testable (no dependencies)
• Data layer can mock external services
• Application layer can mock repositories
• Presentation layer can mock providers

Directory Structure (Recommended)

lib/
├── app/
│   ├── route/           # go_router configuration
│   └── providers/       # App-wide providers
├── features/
│   └── {feature}/
│       ├── domain/      # Entities, Value Objects
│       ├── data/        # Repositories
│       ├── application/ # Providers, Notifiers
│       └── presentation/# Screens, Widgets
└── shared/
    ├── domain/          # Shared entities
    ├── data/            # Shared repositories
    └── widgets/         # Shared UI components

Getting Started

1. New Entity? -> See references/domain-layer.md
2. API Integration? -> See references/data-layer.md
3. State Management? -> See references/application-layer.md
4. Building UI? -> See references/presentation-layer.md
5. Widget Patterns? -> See references/ui-patterns.md

Compliance Verification

# Verify Domain layer purity
grep -r "package:flutter" lib/features/*/domain/
grep -r "riverpod" lib/features/*/domain/

# Verify Data layer isolation
grep -r "package:flutter" lib/features/*/data/
grep -r "riverpod" lib/features/*/data/

# Verify Presentation doesn't access Data directly
grep -r "features/.*/data/.*_repository" lib/features/*/presentation/

All commands should return empty results if architecture is properly maintained.