Architecture Introduction

Flutter applications can be built in various ways, with no single mandatory approach.
This flexibility can pose a challenge for developers, as there are no strict guidelines or a universally accepted structure to follow during the development process.
Consequently, developers must carefully choose their own architectural patterns and best practices to ensure maintainability and scalability.And a typical Flutter app consists of various components, including widgets, navigation routes, background services, state management solutions, event handling mechanisms and a data layer for handling HTTP requests, local caching, and data persistence.As Flutter apps grow in size, it's important to define an architecture that allows the app to scale, increases the app's robustness, and makes the app maintainable and scalable.XFlutter CLI architecture defines the boundaries between parts of the app and the responsibilities each part should have.
In order to meet the needs mentioned above.

Application Layers

Each application should have at least two layers:
  1. The UI layer that displays application data on the screen.
  2. The data layer that contains the business logic of your app and exposes application data.

Modern App Architecture

This Modern App Architecture using some techniques like:
  1. A UI layer with state holders to manage the complexity of the UI.
  2. Unidirectional Data Flow in all layers of the app.
  3. An Isolated Data layer which responsible for bring data from Data Source to UI layer.
Application Layers

UI Layer

The role of the UI layer (or presentation layer) is to display the data on the UI widgets.
Whenever the data changes, either due to user interaction (such as pressing a button) or external input (such as a network response),
the UI should be updated with new data to reflect the changes.

The UI layer is separated to two sub-layers:

  1. UI elements that render the data on the screen such as Text, Image, Input or any Stateless/Stateful widget.
  2. State holders such as (BLoC or Provider) that hold data, expose it to the UI elements, and handle UI events.
    in general we call it ViewModels
UI Layer

Data Layer

The data layer of an app contains the business logic.
The business logic is what gives value to your app—it's made of rules that determine how your app creates, stores, and changes data.The data layer is made of repositories that each can contain zero to many data sources.
You should create a repository class for each different type of data you handle in your app.

Repository classes are responsible for the following tasks:

  1. Exposing data to the rest of the app.
  2. Resolving conflicts between multiple data sources.
  3. Centralizing changes to the data.
  4. Containing business logic.

Data Sources could be something like:

  1. Rest API Client such as Retrofit RestClient or Dio
  2. GraphQL Mutations/Queries.
  3. Local Database such as ObjectBox, Hive or SQLite.
Data Layer

Domain Layer

The domain layer is an optional layer that sits between the UI and data layers.The domain layer is responsible for encapsulating complex business logic, or simple business logic that is reused by multiple ViewModels.
This layer is optional because not all apps will have these requirements.
Domain Layer