ARCHITECTURE.md

Recommended Architecture for Flutter Stores

This document outlines three recommended architectures for using the flutter_stores package. Each architecture balances simplicity, scalability, and flexibility while showcasing the strengths of flutter_stores. These approaches cater to different project sizes and needs.

---

1. Minimal Architecture (Best for Small Projects)

• Focus: Keep it simple with direct use of stores, and limit abstraction layers.
• When to Use: Small projects or prototypes where simplicity and speed are key.

Folder Structure

lib/
├── main.dart
├── screens/
│   ├── home_screen.dart
│   ├── add_task_screen.dart
│   ├── add_category_screen.dart
│   ├── search_screen.dart
├── store/
│   └── todo_store.dart
└── todo_provider.dart

Key Points

• Store Logic:
  • All state management logic is placed in the store (e.g., TodoStore).
• Business Logic:
  • Basic logic stays in the store; no service or repository layer.
• View Access:
  • Access the store directly via TodoProvider.of(context).

Advantages

• Simple and fast to implement.
• Easy to debug due to direct access to state.

Disadvantages

• Not ideal for large projects (limited separation of concerns).

---

2. Modularized Architecture (Best for Medium Projects)

• Focus: Separate business logic into services for better organization and maintainability.
• When to Use: Medium-sized projects with a moderate feature set.

Folder Structure

lib/
├── main.dart
├── screens/
│   ├── home_screen.dart
│   ├── add_task_screen.dart
│   ├── add_category_screen.dart
│   ├── search_screen.dart
├── store/
│   └── todo_store.dart
├── services/
│   └── todo_service.dart
├── models/
│   └── task_model.dart
└── todo_provider.dart

Key Points

• Store Logic:
  • Store focuses on managing state and persistence.
• Business Logic:
  • Moved to services (e.g., TodoService) for reusable and testable business rules.
• Models:
  • Use TaskModel or similar to ensure type safety and consistency.
• View Access:
  • Access the store via TodoProvider.of(context).

Advantages

• Clear separation of concerns.
• Reusable services simplify logic and testing.
• Type safety using models.

Disadvantages

• Slightly more complexity compared to the minimal approach.

---

3. Feature-First Architecture (Best for Large Projects)

• Focus: Organize code by features, allowing each feature to encapsulate its logic.
• When to Use: Large projects requiring scalability and feature isolation.

Folder Structure

lib/
├── main.dart
├── features/
│   ├── todo/
│   │   ├── screens/
│   │   │   ├── home_screen.dart
│   │   │   ├── add_task_screen.dart
│   │   │   ├── add_category_screen.dart
│   │   │   ├── search_screen.dart
│   │   ├── store/
│   │   │   └── todo_store.dart
│   │   ├── services/
│   │   │   └── todo_service.dart
│   │   ├── models/
│   │   │   └── task_model.dart
│   │   └── todo_provider.dart
└── common/
    ├── widgets/
    ├── utils/
    └── themes/

Key Points

• Feature Isolation:
  • Each feature has its own screens, stores, services, and models.
• Shared Logic:
  • Place reusable widgets, utilities, and themes in common/.
• Scalability:
  • Add new features by creating a new folder under features/.

Advantages

• Highly scalable and organized.
• Easy to onboard developers due to clear structure.
• Promotes encapsulation and modularity.

Disadvantages

• Slightly more upfront setup.
• Requires discipline to maintain feature boundaries.

---

Choosing the Best Architecture

1. Minimal Architecture:
   • Great for small projects, simple apps, or quick prototypes.
2. Modularized Architecture:
   • Best for medium-sized apps requiring reusable business logic.
3. Feature-First Architecture:
   • Ideal for large, scalable apps with multiple independent features.

---

These architectures leverage the flexibility and simplicity of flutter_stores, ensuring maintainability and scalability without unnecessary boilerplate. Choose the architecture that best fits the size and scope of your project.